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

linker errors on (regex) on Debian/unstable (gcc-3.4.6)
by Oliver.Kowalke＠infineon.com 17 Feb '06

17 Feb '06

Hello, I've compiled boost-1.33.1 on Debian/unstable with gcc-3.4.6 and get strange linker errors: `.L408' referenced in section `.rodata' of .libs/sys_error.o: defined in discarded section `.gnu.linkonce.t._ZN5boost9re_detail21basic_regex_formatterINS0_19string _out_iteratorISsEENS_13match_resultsIN9__gnu_cxx17__normal_iteratorIPKcS sEESaINS_9sub_matchIS9_EEEEENS_20regex_traits_wrapperINS_12regex_traitsI cNS_16cpp_regex_traitsIcEEEEEEE10format_allEv' of .libs/sys_error.o sys_error.cpp contains: boost::regex e_m("%m"); boost::regex e_e("%e"); std::string f( format); f = boost::regex_replace( f, e_m, msg, boost::match_default | boost::format_sed); return boost::regex_replace( f, e_e, ::strerror( errno), boost::match_default | boost::format_sed); Could you please tell me howto fix this. Regards, Oliver

1 0

Asymmetrical predicates in STL algorithms
by Max Motovilov 17 Feb '06

17 Feb '06

I only stumbled to this problem recently, after happily using the patently unportable solution for years (with numerous versions of STL to boot). Let's say we have a sorted vector of complex objects with a fairly simple key, and want to do lower_bound() on just a key, not a specially constructed instance of the whole object. It turns out that: bool less( const Object&, const Key& ); lower_bound( v.begin(), v.end(), Key(something), ptr_fun(less) ); is expressly prohibited by the SGI STL specifications and not quite allowed, even though not quite prohibited either, by the ISO standard (unless my standardese grew rusty again). It also turns out that there are STLs where it won't work (e.g. the new Plauger's STL shipped with VStudio 2005 release, but not beta 2...). Now, this: struct less { bool operator()( const Object&, const Key& ) const; bool operator()( const Key&, const Object& ) const; }; lower_bound( v.begin(), v.end(), Key(something), less() ); should work everywhere, or so I think. Would be nice to be able to create such an adaptor for a pair of functions (or a pair of bind or lambda expressions for that matter). I blogged a simple solution (for functions only) here http://swsw.motovilov.net/weblogs/swsw/archives/2006/02/asymmetrical_pr.html but am wondering if perhaps I missed a generic solution in one of the Boost libraries, or there's one coming in the new release? Any comments/suggestions? Regards, ...Max...

2 3

compiling just one library
by Adrian Grigore 16 Feb '06

16 Feb '06

Hi, How can I compile just a few of the boost libraries? For example I tried bjam ..... --with-filesystem install, but that did not seem to have any effect, it just resulted in a regular compilation of all libraries. Thanks, Adrian Grigore

2 1

Re: [Boost-users] compiling just one library
by Sohail Somani 16 Feb '06

16 Feb '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Adrian Grigore > Sent: Thursday, February 16, 2006 12:47 PM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] compiling just one library > > Hi, > > How can I compile just a few of the boost libraries? For example I > tried bjam ..... --with-filesystem install, but that did not seem to > have any effect, it just resulted in a regular compilation of > all libraries. cd path/to/library && bjam install usually does it for me.

1 0

[program_options] Multiple segfaults
by David Greene 16 Feb '06

16 Feb '06

I'm starting to use boost::program_options and am not having much luck: >>-home-> ./options_test Got debug value default Got option default Segmentation fault (core dumped) >>-home-> ./options_test --help free(): invalid pointer 0x8fb06f8! free(): invalid pointer 0x8fafcd0! Got debug value default Got option default Segmentation fault (core dumped) >>-home-> ./options_test --help --debug io free(): invalid pointer 0x8a83ec0! free(): invalid pointer 0x8a83ed0! free(): invalid pointer 0x8a83ec8! free(): invalid pointer 0x8a84a38! Segmentation fault (core dumped) At first I thought it might be a problem with the -mt version as my larger application is threaded. But I compiled the testcase attached below as a single-threaded application and it still fails in the same ways. I'm not sure if my use of vector<string> is correct. The documentation is confusing on this point. In http://boost.sourceforge.net/doc/html/program_options/overview.html one example with the "email" option uses multitoken with "string" and another uses "combining" with "vector<string>." Is it not possible to have a combining and multitoken option value? What's the correct value type to use if I want the multiple tokens for the "debug" option to appear as separate items in a vector (or other sequence)? Or do I have to stuff them in a single string and manually parse them out later? -Dave ------------------------ #include <boost/bind.hpp> #include <boost/program_options.hpp> //#include <boost/filesystem/operations.hpp> //#include <boost/filesystem/fstream.hpp> #include <vector> #include <string> #include <iostream> #include <algorithm> #include <iterator> std::ostream &operator<<(std::ostream &out, const std::vector<std::string> &value); std::ostream &operator<<(std::ostream &out, const std::vector<std::string> &value) { std::copy(value.begin(), value.end(), std::ostream_iterator<std::string>(out, " ")); return(out); } namespace test { namespace opt = boost::program_options; //namespace fs = boost::filesystem; static void validate_debug_options(const opt::options_description &debug, const std::vector<std::string> &value) { std::cout << "Got debug value " << value << std::endl; for(std::vector<std::string>::const_iterator i = value.begin(); i != value.end(); ++i) { std::cout << "Got option " << *i << std::endl; } } void process_options(int argc, char **argv) { opt::options_description help("Help options"); opt::options_description debug("Debug options"); opt::options_description cmdline_options; opt::options_description cfgfile_options; help.add_options() ("help", "This help message"); typedef std::vector<std::string> option_vector; option_vector default_debug_flags; default_debug_flags.push_back("default"); debug.add_options() ("debug,d", opt::value<std::vector<std::string> >()-> // For some reason can't find operator<< declared above default_value(default_debug_flags, "default")-> composing()-> multitoken()-> notifier(boost::bind(validate_debug_options, boost::ref(debug), _1)), "Debug flags:\n\n" " foo: \tDo something\n" " bar: \tDo something else\n" " baz: \tDon't do anything\n"); cmdline_options.add(help).add(debug); cfgfile_options.add(debug); opt::variables_map vm; opt::store(opt::parse_command_line(argc, argv, cmdline_options), vm); // fs::ifstream config_file("./opt.cfg"); // if (config_file) { // opt::store(opt::parse_config_file(config_file, cfgfile_options), vm); // } opt::notify(vm); } } int main(int argc, char **argv) { test::process_options(argc, argv); return(0); }

3 6

Using boost bind library to loop thru a list
by Meryl Silverburgh 16 Feb '06

16 Feb '06

I have a int vector, and I would like to loop thru the vector and call a function which takes an int (in this case, I want to print). void A::aFunction() { vector<int> aVector; aVector.push_back(1); aVector.push_back(2); aVector.push_back(3); aVector.push_back(4); // want to loop thru the list and call A::print(int i)? } void A::print(int i) { } how can I do that using boost bind library?

7 10

hardware bit set, clr, tst templates
by Perry Smith 16 Feb '06

16 Feb '06

Before I jump off and re-invent the wheel -- is there a boost library to help with manipulating hardware registers? What I'm hoping to come up with (somehow) is something like: class dev_registers { reg<uint32_t> reg0; bit<reg0, 0> b0; bit<reg0, 1> b1; reg<uint32_t> reg1; bit<reg1, 0> b3; bit<reg1, 1> b4; }; (The 0 and 1 are bit offsets. Integer masks like 0x0010 would work as well) The result would be a private members of type uint32_t called reg0, and reg1 (actually they can be called anything since they are private). And a set of public methods to set, clear, and test the bits. e.g. dev_registers sample; sample.b0.set(); sample.b3.clr(); It would be nice if the registers had a global clr like: sample.reg0.clr(); There are lots of alternative approaches like: sample.b0.assign(true); // set b0 to true (1) int val = sample.b0(); // test value of b0 The goal has a lot of constraints. The registers would need to be laid out properly without any extra overhead (assuming that I do not bump into normal C padding problems). It would also be nice if everything inline'd so the compiler could optimize things down to simple bit operations. Does boost have anything like that? I looked for "bit" and only found references to bitset. I also looked for "hardware" and "flag" and did not see anything. Thanks, Perry

1 0

[Graph] New user finding dijkstra's isn't returning shortest paths
by Greg Link 16 Feb '06

16 Feb '06

In my first use of the boost library, I'm using the BGL's dijkstra_shortest_paths algorithm to try and (obviously) find the shortest path between two points. I am then iterating along the shortest path to a given node to find the total path weight along that path. I compare this value to the path weight along a manhattan path, and find that the manhattan path is shorter. Rather than claim this is a problem with boost (yet), I'm at first believing it's my interpretation of the library. If I've piqued your interest, feel encouraged to read on. My graph is a representation of a 2-dimensional mesh, so I've got an NxN graph, where the vast majority of nodes have out-edges in all four directions (N,S,E,W), and in-edges in all four directions. I generate the graph with the following: typedef adjacency_list < listS, vecS, undirectedS, no_property, property < edge_weight_t, double > > graph_t; graph_t gGraph(num_nodes); then iterating over each node (i) and adding edges as follows: add_edge(i, easterlydest, easterlyweight, gGraph); finally, I call: dijkstra_shortest_paths(gGraph,sourcenum,predecessor_map(&p [0]).distance_map(&d[0])); to evaluate the shortest paths. (Note that much of this is a cut-and- paste from the Dijkstra_shortest_path example found at http:// www.boost.org/libs/graph/example/dijkstra-example.cpp ) Note also that my understanding of the last argument to dijkstra_shortest_paths is probably my weakest part of understanding the library. I then iterate along a given shortest path by using the following loop structure: while(node != sourcenum) // iterate from dest to source, summing as you go { int u = p[node]; int v = node; graph_traits < graph_t >::edge_descriptor e = edge(u,v,graph).first; double this_weight = get(edge_weight,graph,e); path_length += this_weight; node = p[node]; } This returns a value of 1309.16 as the total path weight. I then attempt to determine the manhattan path weights as well, to compare how much of an improvement the shortest path is to the manhattan paths. I attempt to traverse the manhattan paths using a similar approach, with something similar to the following (irrelevant lines omitted): while(node != destnode) // iterate from source to dest, iterating as you go { int nextnode = get_nextnode(xfirst,node); // gets index of next node in an x-first y-next manhattan path int u = node; int v = nextnode; graph_traits < graph_t >::edge_descriptor e = edge(u,v,graph).first; double this_weight = get(edge_weight,graph,e); xfpath_length += this_weight; node = nextnode; } When this runs, I get a path length of 1299.79, a value more than 0.1% smaller. Either I'm determining the manhattan and shortest path weights incorrectly, or it's not actually finding the shortest path. So I did a bit of debugging (as programmers are wont to do). Tracing the paths themselves, I eventually find that at one point, the shortest path (hereafter abbreviated DSP) chooses to follow an out- edge that doesn't have minimum weight. This is perfectly reasonable, as it's possible (and probable) that this choice made now, will have greater returns later, allowing an overall shorter path. However, it never again returns to even equality with the manhattan path - the manhattan path is shorter along the entire length, to the end. I've checked my corner cases, and the paths are only being summed along relevant edges (no off-by-one errors that I can see, at least). If anyone has any ideas on how I might best debug/change my code, or a means by which I can perform some other test, I'd love to hear it. If anyone needs any more information, the code is by no means confidential (though a bit messy) and I've got both .dot (graphviz) format and an svg representation of the graph available. My development platform is currently Mac OS X 10.4.4 PPC using Xcode, if it matters to anyone. Thanks, and I hope you don't mind the rather lengthy post! - Greg Link ---- 20 70 80 95 106

2 2

Re: [Boost-users] Non-boost c++ novice help
by Matt Davies 16 Feb '06

16 Feb '06

I don't think it is the appropriate place. You need to make it static as well to be in the class: static const uint64_t mask = 0x12345678 Cheers, Matt Davies Rockstar Leeds -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Perry Smith Sent: 16 February 2006 15:43 To: boost-users(a)lists.boost.org Subject: [Boost-users] Non-boost c++ novice help If this is not an appropriate list for this question, please let me know. The books tell me to prefer const to #defines -- but where do you put them to have the right scope and not take up space in the object? What I'd like to have is: class register { void set_mask() { reg |= mask; } private: uint64_t reg; const uint64_t mask = 0x12345678; }; But the compiler will not let me do this and even if it did,the mask would take up physical space. I don't want mask (or reg) to be visable outside of the class and I want the compiler to use mask as a compile time constant that does not consume space after the compile. I vaguely know about namespace but if I put this inside a namespace, then I have to do: namespace hardware { const mask = 0x12345678; class register { void set_mask() { reg |= mask; } private: uint64_t reg; }; }; // .. define a register hardware::register doddy; and "mask" is not really private -- just obscured. I can still do: int i = hardware::mask; This just feels like I've taken a wrong turn somewhere. How would this be "properly" done? Thanks, Perry _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

[TR1] Where is the TR1 library?
by Scott Meyers 16 Feb '06

16 Feb '06

Google found me a 12 October 2005 posting by Beman Dawes to this newsgroup stating that John Maddock's TR1 library has been accepted by Boost. But if I search for TR1 at http://boost.org/libs/libraries.htm, I don't find the library. Searching more generally yields lots of hits at www.boost.org/regression-logs/ (e.g., http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boost_tr1.h…) and this suggests that just because a library has been accepted by Boost doesn't mean it will show up in the list at http://boost.org/libs/libraries.htm. Can somebody please explain to me what are probably the basics of what it means to be "in" Boost, how that interacts with the list of Boost libraries at boost.org, and what the significance of the regression-logs directory is? If this is explained somewhere at Boost, just point me to the page. Thanks, Scott

3 6