- Boost-users - lists.boost.org

regex static lib for x86 emulator
by Reuti＠sdc.canon.co.in 20 Nov '03

20 Nov '03

I can build static library for ARM processor. But when building for X86 emulator I am getting following error. LINK : fatal error LNK1104: cannot open file 'boost_regex_vc6_sss.lib' Please help. Thanks in advance. Reuti

1 0

gregorian: explicit date::date(date_int_type) ?
by Michael Haubenwallner 19 Nov '03

19 Nov '03

Hi, I'm preparing my company's step from C to C++, and when i use boost::date_time::*, there's a great danger to make mistakes like this with boost-1.30.2: #include <time.h> #include <iostream> #include <boost/date_time/posix_time/posix_time.hpp> using namespace boost::posix_time; using namespace boost::gregorian; int main() { time_t now = time(0); try { ptime time(now); // mistake cerr << to_simple_string(time) << endl; } catch (exception const& e) { cerr << "error: " << e.what() << endl; } } The problem is that the time_t in this case is treated as a day-count from which a gregorian::date() is implicitly constructed. When digging through the gregorian::date, i see that the constructors of date_time::date() from date_int_type and date_rep_type protected. So, wouldn't it be better to make the gregorian::date() constructors from date_int_type and date_rep_type explicit, to get a compile-time error with this sample rather than the out-of-range-exception "Year is out of valid range: 1400..10000" ? And another reason to make this constructor explicit might be that date_rep_type is the internal representation of date(), so when constructing date() with a day_count, you have to know the epoch, and then constructing date() should be done explicitly... What do you think about this ? Thanks, Michael Haubenwallner -- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz T +43 3127 200 308 F +43 3127 200 22 mailto:michael.haubenwallner@salomon.at http://www.salomon.at

2 3

Invert Matrix
by JEFFREY CULLINA 19 Nov '03

19 Nov '03

I have devoleped code to derive a simple matrix expression: [K]*[D]=[R] wher D is an unknown vector. I am looking for code to do two things: 1. Invert [K] to get the expression [D]=inv([K])*[R] 2. Solve the equation in 1 It looks like the UBLAS toolkit provides a function _t_sv to solve the equation, but I do not see anything to help me invert the matrix. Is there code available to help me invert a matrix? While I am at it, I may as well ask if _t_sv is the best function to use to solve the system. Thanks, Jeff

1 0

Smart pointers and STL allocators
by Mark A. Gibbs 19 Nov '03

19 Nov '03

I have a couple of questions about combining smart pointers and STL allocators. First of all, am I right in assuming that I can use the shared_* templates right out of the box, as long as I define a custom deleter that uses the allocator's deallocate function? But if that's so, how exactly is it done? Part of my confusion comes from the fact that the STL allocator documentation I've come across isn't exactly clear on the semantics of allocators (I don't have a copy of the standard). For instance, I'm not 100% sure whether or not I have to call construct() after allocate() and destroy() before deallocate(). This is what I have so far: class allocator_helper { public: allocator_helper(allocator_type& a) : a_(a) {} void operator()(void const* p) const { a_.deallocate(static_cast<allocator_type::pointer>(p)); } private: allocator_type& a_; }; foo* bar = static_cast<foo*>(get_allocator().allocate(1)); shared_ptr<foo> p_foo(bar, allocator_helper(get_allocator())); foo* baz = static_cast<foo*>(get_allocator().allocate(10)); shared_array<foo> p_foo(baz, allocator_helper(get_allocator())); Now, for scoped_* I would probably have to rewrite them to use the allocator, right? Or is there a way to use allocators with the existing scoped_* templates? Mark

2 3

regex problems
by Paul Scruby 19 Nov '03

19 Nov '03

The boost::regex class is crashing when I construct it with some regular expressions. For example: "(value|default)[^}]*\{" will crash and "value|default" does not. Is this a bug, or am I doing something wrong? I am running gcc2.96 and boost1.30.2. I have attached an example src including Makefile. Thanks in advance, Paul

3 3

Newbie question, linking problems
by Mrk 18 Nov '03

18 Nov '03

Hello, I'm trying to get regexp to work under vc6, STL 4.5.3 and boost 1.30.2 but sadly I'm running into some problems. Did anyone ever had this problem with the following methods ? error LNK2001: unresolved external symbol "public: static void __cdecl boost::w32_regex_traits<char>::transform_primary( ... error LNK2001: unresolved external symbol "public: static void __cdecl boost::w32_regex_traits<char>::transform( ... Thanks, Mrk

1 0

Re: [Boost-users] [BGL] Problem with color maps for undirected_dfs_visit
by Jeremy Siek 18 Nov '03

18 Nov '03

Hi Tarjei, On Friday, November 14, 2003, at 05:33 AM, Tarjei Knapstad wrote: > On Thu, 2003-11-13 at 17:09, Jeremy Siek wrote: >> Hi Tarjei, >> >> You need to initialize the edge index property map (only the vertex >> index >> map is automatically initialized, and then only for VertexList=vecS). >> > > Hmm, ok, but I still don't quite understand. I thought that > initializing > the std::vector holding the colors was sufficient...? To my > understanding an iterator_property_map is just a property map which > iterates through some other container (that can provide a > RandomAccessIterator) actually holding the properties? Yes, your edge color map is initialized just fine, but you also need to initialize the edge index map. Here's the reason why: your edge color map uses the edge index map to go from an edge descriptor to an integer offset, which is then used to access into the color vector. Currently, your edge index map is initialized to random garbage, so you are going out-of-bounds when accessing the edge color vector. See the example file exterior_properties.cpp, BTW, you don't need to declare an edge_color property for the adjacency_list because you are using an external edge color map. > > Obviously there's some connection I don't quite get here... I also > don't > quite understand the EColorValue uv_color = get(edge_color, *ei); call > in undir_dfv_impl. It asks for the edge_color at the edge_descriptor > *ei, but from where? > > Anyway, I don't really even need an edge_index property here (or do > I?), > it was more or less to try to get this working. Yes, you need it for the reason given above. BTW, if you switch to using an internal edge color property, then you won't need the edge index property, or the edge color vector. Cheers, Jeremy

2 1

GRAPHVIZ_DIRECTED macro definition?
by Soumitra Chatterjee 18 Nov '03

18 Nov '03

Hi, In the file .../libs/graph/src/graphviz_parser.y we have the following: #ifndef GRAPHVIZ_DIRECTED #error Need to define the GRAPHVIZ_DIRECTED macro to either 0 or 1 #endif I couldn't locate the definition for the above macro in my boost installation. Do we need to define it explicitly, or am I missing some file(s)? Thanks, Soumitra

2 1

Error 112: Missing directory LEDA
by Soumitra Chatterjee 17 Nov '03

17 Nov '03

Hi, I have downloaded boost-1.30.2, and while trying to compile/test it, I am getting the error(s): Error 112: "/TESTC++/Boost-1.30.2/boost/graph/leda_graph.hpp", line 33 # Include file <LEDA/graph.h> not found. #include <LEDA/graph.h> ^^^^^^^^^^^^^^ [...snip...] The directory 'LEDA' seems to be missing from the downloaded package. Have I missed something during the install process, or is there something else to be done after unpacking the installation package? I am using JAM for the build. Thanks, Soumitra

3 2

Re: Intoductory Boost Presentation
by Jorg Brown 17 Nov '03

17 Nov '03

Matt - The corrected code is indeed much better. May I suggest using std::vector instead of vector? The typedef of FooPtr is fine, it turns out; it's the typedef of struct Foo that was the problem. I had declared Foo within main as well, and that blocks the use of boost::shared_ptr on it. As long as Foo is declared at global scope, all is well. As for the correct output, my compiler gives me 3, then 2, then 1. I talked it over with a friend, and I guess the order of the 2 vs 1 is undefined, and depends on your STL's implementation of std::vector. As for the crazy aunt in the basement, the comment was meant for an internal list that only 20-30 people are on, not meant for general consumption, and probably merits an extra thread by itself. Put simply, using boost can generate a surprising amount of code and overhead. This is true of STL as well. There are even some good books describing STL; I happen to like Plauger/Stepanov/Lee/Musser, as well as Jasoutis. But nowhere do I see any reference as to what the downsides are - and nowhere do I see any concise explanation of why an enormous amount of code (660 bytes in an optimized, no-symbols build) is generated when I say something as simple as void Testbed(void) { boost::function<void> SimpleFPtr(&Testbed); } When you say "I was trying to generate interest in these libraries and thus didn't want to focus too much on the negatives", I can understand your point of view, but what I see in real life is that people start using boost::function everywhere they used to use plain old function pointers, with nary a clue that their code size just exploded with no benefit. But like I said, it's worth a whole other thread. Thanks for fixing the code and responding so quickly! jorg -----Original Message----- From: "Matt S Trentini" <matt_s_trentini(a)hotmail.com> Reply-To: Boost Users mailing list <boost-users(a)lists.boost.org> Date: Tue, 11 Nov 2003 23:19:12 +1100 To: boost-users(a)lists.boost.org Subject: [Boost-users] Re: Intoductory Boost Presentation Heya Jon, Ah, the smart_ptr example, I knew that would come back to bite me! ;) I changed this example at the last minute in an effort to simplify but, as your co-worker correctly points out, there are many errors in it. The correct code is below though the graphic requires change (yes, I could have change the list.push_front() to a push_back but I like to see the variety!). int main() { typedef boost::shared_ptr<Foo> FooPtr; vector<FooPtr> foo_vector; list<FooPtr> foo_list; FooPtr foo_ptr( new Foo(1) ); foo_vector.push_back( foo_ptr ); foo_list .push_back( foo_ptr ); foo_vector.push_back ( FooPtr( new Foo(2) ) ); foo_list .push_front( FooPtr( new Foo(3) ) ); } You'll notice that I left the typedef in there. I can't find anything in the standard (or with google) about it being illegal in main, nor does my compiler emit any warnings. Can anyone shed some light on this? And I've got to disagree with your friend about the correct ordering - the expected output is 3, 1, 2 (Remember that foo_ptr gets deleted first). I'll endeavour to fix this example up and upload the changes over the next couple of days. As for these comments: > > The rest of the pages have the classic boost downfall: they > > don't discuss any of the pitfalls, performance problems, or > > code bloat issues, which frankly, seem like the "crazy aunt > > in the basement" of boost. I'll defend myself on two fronts. First, it's an introductory presentation - I was trying to generate interest in these libraries and thus didn't want to focus too much on the negatives. Secondly, I _did_ cover some of those points - like all good presentations not everything is contained in the bullet points. Thanks for the feedback though, it's helping to make this presentation better! Cheers, Matt PS If there are any other problems that you or your co-worker have found please don't hesitate to report them! _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ------ End of Forwarded Message

3 2