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

regex problems
by Paul Scruby 18 Nov '03

18 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 17 Nov '03

17 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 17 Nov '03

17 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 17 Nov '03

17 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 16 Nov '03

16 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

Intoductory Boost Presentation
by Matthew S Trentini 16 Nov '03

16 Nov '03

Heya Everyone, I recently gave a presentation to my work colleagues on the wonders of the Boost library. Many weren't aware of what it was or what it could do so it just contains an overview and some coverage on nine of the libraries (with short code examples). It went for nearly an hour and was pretty well received, so I thought that maybe someone else out there could use the material. Please feel free to download (it's in a variety of formats) from here: http://www.alphalink.com.au/~mattyt/BoostPresentation1/boost.html Cheers, Matt PS If you want to modify/publish/whatever that's fine... _________________________________________________________________ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp

7 10

Re: [Boost-users] Building Regex++ lib on Pocket PC using EmbeddedVC++4.0
by Reuti＠sdc.canon.co.in 16 Nov '03

16 Nov '03

Thanx. With latest version I could build but I could not create import library corressponding to dll created. Is there some macro for this? ===== Reuti "John Maddock" <john(a)johnmaddock.co.uk> To: "Boost Users mailing list" <boost-users(a)lists.boost.org> Sent by: cc: boost-users-bounces@list Subject: Re: [Boost-users] Building Regex++ lib on Pocket PC s.boost.org using EmbeddedVC++4.0 11/13/2003 05:32 PM Please respond to Boost Users mailing list > Has anyone tried building regex++ lib for PPC using EVC++? I've never tried with that compiler - I think it's even worse than VC6 for conformance? > I can build it using VC++6.0 using the .mak files supplied with it.But I am > getting errors and warnings. > Error is regarding the use of typename keyword in lib source and warning is > about C++ Exceptions unwinding capability. Defining BOOST_NO_EXCEPTIONS should fix that - in fact it should get automatically set for vc with no eh support, so there could be a config bug there. > I replaced C++ try, catch by Win32 __try , __except but don't know what to > do with template error? What is there error: you may be able to just remove the typename keyword to fix the problem? John. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Preprocessor Metaprogramming Problem
by Mitch 16 Nov '03

16 Nov '03

I'm trying to figure out the longest sequence in a sequence. Here's the MACRO I tried. #define OP(size, state, elem) BOOST_PP_MAX(state, BOOST_PP_SEQ_SIZE(elem)) #define MACRO(seq) BOOST_PP_SEQ_FOLD_LEFT(OP, 0, seq) If I process ((a)(b))((c)) I get 2 back as expected. However, the extra parenthesis seems awkward. I'd like to process ((a)(b))(c) instead, but can't. The '(c)' gets coverted to plain 'c' as the elem parameter to OP and that's not a valid sequence. Any ideas? Mitch

1 0

boost::shared_ptr performance
by Matthew Wilson 15 Nov '03

15 Nov '03

[I posted this in boost.devel, but got no response. Presumably that was the wrong group. :)] Hi Boosters I'm just doing some research on reference-counting, and contrasting self-counting types with externally counted types, the latter effected with the rather excellent shared pointer technique. [As a side question, is it true that Nicolai Josuttis was the inventor of the technique?] Naturally, one of the shared pointer's I've used is boost::shared_ptr. The measurements have demonstrated some surprising performance characteristics for shared_ptr in particular, and I want to solicit the opinion of the expert's here before I make any bold claims, as some results are just too surprising for me to trust them. There are five types tested. 1. A self-counting type, using an ancient Synesis (my company) template ref-counting bolt-in class 2. A self-counting type, using a custom-written (for this test) template ref-counting bolt-in class 3. Externally counting, using boost::shared_ptr 4. Externally counting, using a custom-written (for this test) shared pointer type 5. Externally counting, using a custom-written (for this test) shared pointer type, which has a custom allocator for the shared count members There were three scenarios investigated, and the same algorithms were applied to the above five types A: Saving refs vector<smart-ptr> ptrs; loop (100,000 times) { smart-ptr sp1(new Thing); sp1 = sp1; smart-ptr p2; p2 = p1; smart-ptr p3(p1); smart-ptr p4(p3); smart-ptr p5(p4); smart-ptr p6(p5); process_Thing(p6.get()); // A function to do something (actually it just returns the result of a call on Thing) to prevent elision by optimisation ptrs.push_back(p5); } The whole is executed within a single thread, and the program is tested in both single and multithreaded forms. B: Discarding refs This is identical to A ("Saving refs") except that saving them to the vector of ptrs is omitted. Again, this is done in one thread, and single and multi-threaded forms tested C: Multi-threaded sharing 20 smart-pointers are created, containing 20 Thing instances, in the main thread. Then 20 threads, using the following thread-proc, are created, and executed. Two times are recorded for each scenario: the total time, and the sum of the individual thread-times (obtained by the WinSTL threadtimes_counter, based on the Win32 API function GetThreadTimes()) std::vector<ptr_type> ptrs(ITERATIONS / 10); for(size_t i = 0; i < 10; ++i) { for(size_t j = 0; j < ITERATIONS / 10; ++j) { ptrs.push_back(things[i % things.size()]); } } ITERATIONS is 100,000. things is the shared shared_ptr array The purpose of this one is to really exercise the sharing between threads. Results (all results are expressed in terms of the most costly pointer) ============================================= [Note, all were compiled with Intel 7.0 with very aggressive speed optimisations (-O2 -Ox -QaxMKW /Qvc7 -EHsc), and executed in a single session on an otherwise quiescent 512MB 2GHz XP box.] A (single-threaded) -------------------- 1. Synesis self-counter: 65% 2. Custom self-counter: 58% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 53% 5. custom SharedPtr + rc pool): 48% I was not surprised that the crusty old Synesis type was slower than the custom self-counter. As expected, the custom shared-ptr with rc pool was the fastest. I was a little surprised that the Boost shared_ptr was up to twice as slow. However, they're all within 100% of each other, so it's no big result I guess. A (multi-threaded) -------------------- 1. Synesis self-counter: 90% 2. Custom self-counter: 46% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 28% 5. custom SharedPtr + rc pool): 27% This was surprising. I expected the use of thread-safe operations (atomic increments, etc.) to flatten out the curve, but the reverse has happened. Interestingly, the two real-world types (Synesis::RefCounter and boost::shared_ptr) fair less well. Again, not what I expected. B (single-threaded) -------------------- 1. Synesis self-counter: 65% 2. Custom self-counter: 55% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 59% 5. custom SharedPtr + rc pool): 53% This scenario has a lot more reference-increments, and a lot less deallocation of the reference-counted instance. Nonetheless, the results are virtually identical, in relative terms (the actual times taken are about 50% across the board). B (multi-threaded) -------------------- 1. Synesis self-counter: 71% 2. Custom self-counter: 41% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 32% 5. custom SharedPtr + rc pool): 31% Pretty much the same as with B (single-threaded). The results are the same, in relative terms Up to this point, the results are mildly interesting, but nothing earth shattering. C - (Times are total time, and thread times, respectively) 1. Synesis self-counter: 2.9% 39% 2. Custom self-counter: 2.7% 35% 3. boost::shared_ptr: 100% 100% 4. custom SharedPtr: 1.0% 13% 5. custom SharedPtr + rc pool): 1.2% 15% This scenario tells quite a different tail indeed. One thing to note is that because of the degree of reference-sharing between the ptr-storing vectors in the 20 threads, the ref-count-pool becomes a pessimisation as a result of the number of actual smart pointer instances being created exceeding the arbitrary 1024 cached ref-counts available. It's likely that this number would not be exceeded in real-world scenarios, so the pool is probably still worth having. Naturally, the very big question is: what's happening to boost::shared_ptr? In thread times, it performs 2-3 times worse than in single threaded scenarios (irrespective of whether they are built for single or multiple threads). However, in total time, it performs extremely poorly, up to 100 times slower than some of the others! Clearly, there is some serious contention involved. There are three possibilities I have thought of: (i) It performs very poorly in multi-threaded sharing scenarios. If this is the case, can any people more expert in Boost than me proffer an explanation as to precisely the problem, and is any such person motivated to try and address the issue? (ii) The particular sharing scenario is well away from any real-world scenario in which boost::shared_ptr is likely to be used. If this is the case, why do four different implementations, representing two very different reference-counting strategies, all maintain a consistent relative performance? What are the scenarios for which boost::shared_ptr is optimised? (iii) There are environment settings for which boost::shared_ptr will perform much better. If that's so, can someone help me out with suggestions of what defines to make? Why are these settings not the default. I'd be very interested in your thoughts. Many thanks in advance. -- Matthew Wilson STLSoft moderator (http://www.stlsoft.org) Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) "You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael ---------------------------------------------------------------------------- --- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Property map deletion
by David Ohlemacher 14 Nov '03

14 Nov '03

Hi all. Partway through my app's execution, I find that I no longer need the values in a custom property map (edge). The map potentially may be quite large. What is the best way to empty it? Thanks, -d

3 7

Boost and Windows CE - does it?
by Steve Folly 14 Nov '03

14 Nov '03

Hi, I know the real answer is probably to just 'try it', but I thought I'd ask to see if anyone else has tried this. We have an application framework which makes extensive use of boost, particularly shared pointers. Currently, we can build Win32 and Mac Carbon applications. Has anyone successfully built applications utilising boost for Windows CE? In particular, we've just started looking at the eMbedded Visual C++ 4.0 compiler and the Pocket PC 2003 SDK. -- Regards, Steve.

1 0

Re: 'long long' problem on VC++7.1
by Nick Savoiu 14 Nov '03

14 Nov '03

And here's what's missing.... I'm using the /Za switch (Disable Language Extensions). But I'm a bit puzzled. I would have thought that /Za (a more standard compliant mode) would not fail. Nick "Nick Savoiu" <savoiu(a)ics.uci.edu> wrote in message news:... > That would be a solution but 'long long' appears in quite a few places. So, > I think there's something else that I'm missing... > > Nick > > "Jeff Garland" <jeff(a)crystalclearsoftware.com> wrote in message > news:20031111022332.M81509@crystalclearsoftware.com... > > On Mon, 10 Nov 2003 14:14:04 -0800, Nick Savoiu wrote > > > I'm trying to compile some boost code on VC+7.1 but I get: > > > > > > e:\users\savoiu\Projects\boost-1.30.2\boost\concept_check.hpp(183) : > > > error C2632: 'long' followed by 'long' is illegal > > > > > > Do I need any #defines when using Boost with VC++7.1 or should it > > > work right out of the box? > > > > I believe this is an error in the concept_check code. Try changing the > 'long > > long' to boost::int64_t. > > > > Jeff > >

2 5

Compiler error with STLport-4.6
by Peter Westerstrom 14 Nov '03

14 Nov '03

Hello, I get this internal compiler error below when compiling boost-regex (from cvs today 11 nov 2003) using STLport-4.6. The error do not show up when using STLport-4.5.3 though. Any ideas? Problem in STLport-4.6 or boost, that's the question? cl -Ic:\EON\builds\head\Development\ExternalLibraries\include\stlport /nologo /MT /W3 /GX /O2 /GB /GF /Gy /Ic:\EON\builds\head\Development\ExternalLibraries\include\stlport /I..\..\..\ /D_MT /DWIN32 /DNDEBUG /D_MBCS /D_LIB /c -DBOOST_REGEX_STATIC_LINK -D_STLP_USE_STATIC_LIB -D_RTLDLL -Y- -Fo./vc6-stlport/libboost_regex-vc6-mt-sp-1_31/ -Fdvc6-stlport/libboost_regex-vc6-mt-sp-1_31.pdb ../src/c_regex_traits.cpp Command line warning D4002 : ignoring unknown option '-Y-' c_regex_traits.cpp ..\..\..\boost/detail/allocator.hpp(67) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Peter Westerstrom peterw(a)eonreality.se

3 4

RE: [Boost-users] Building Regex++ lib on Pocket PC using EmbeddedVC++4.0
by Ben Hutchings 14 Nov '03

14 Nov '03

Reuti(a)sdc.canon.co.in <Reuti(a)sdc.canon.co.in> wrote: > Has anyone tried building regex++ lib for PPC using EVC++? > I can build it using VC++6.0 using the .mak files supplied > with it.But I am getting errors and warnings. > Error is regarding the use of typename keyword in lib source > and warning is about C++ Exceptions unwinding capability. > > I replaced C++ try, catch by Win32 __try , __except That isn't going to help you. While the Win32 exceptions will be caught and thrown there will be no unwinding of the stack, i.e. destructors for automatic variables will *not* be called. So the code will not work correctly in case of an exception. The approach I've seen is to call abort() instead of throwing, which is probably not a very good one. > but don't know what to do with template error? > > Can anybody help in this? > Also can it be confirmed that its possible to port it on Win CE? Not with EVC++. I'm afraid it's something of a waste of time to try to compile standard C++ code with it. There has been some work to port GNU C++ to WinCE but it is incomplete and so far as I know only covers SH3 and MIPS whereas the most popular architecture for WinCE now seems to be ARM.

5 5

[BGL] Problem with color maps for undirected_dfs_visit
by Tarjei Knapstad 14 Nov '03

14 Nov '03

I'm trying to implement a DFS visitor and using it with undirected_dfs_visit, but I'm getting a segfault which relates to the edge color map. I've made the following test app for illustration: **************** START CODE **************** #include <vector> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/undirected_dfs.hpp> using namespace boost; struct Types { typedef adjacency_list<vecS, vecS, undirectedS, property<vertex_color_t, default_color_type>, property<edge_color_t, default_color_type, property<edge_index_t, int> > > GraphType; typedef std::vector<default_color_type> ColorVec; typedef color_traits<default_color_type> Color; }; int main() { Types::GraphType g(6); add_edge(0,1,g); add_edge(1,2,g); add_edge(2,3,g); add_edge(2,4,g); add_edge(4,5,g); Types::ColorVec v_colors(num_vertices(g), Types::Color::white()); Types::ColorVec e_colors(num_edges(g), Types::Color::white()); default_dfs_visitor visitor; undirected_depth_first_visit(g, 0, visitor, make_iterator_property_map(&v_colors[0], get(vertex_index, g)), make_iterator_property_map(&e_colors[0], get(edge_index, g))); }; **************** END CODE **************** The code crashes in undirected_dfs.hpp line 73 the first time it's trying to access a color from the edge color map: EColorValue uv_color = get(edge_color, *ei); Valgrind turns up a lot of illegal reads/writes to the edge_color_map as well, so I'm guessing that I've screwed up on the colormap creation. Could anyone point out my error? Also, is this an error that could be caught compile time by adding some sort of concept check? Thanks in advance for any help! Regards, -- Tarjei

2 2

Boost.Thread: inlined constructor in thread_specific_ptr block application start up
by Roland 14 Nov '03

14 Nov '03

Dear Boosters, I am trying to understand how to use the TSS Thread local storage, and came upon a strange behaviour. I do not know if I am doing something wrong here. Maybe someone can help. I am running on Win2K, VC6.0. (GUI Interface programm type) In my main thread I have: struct oops { // inline oops(); // commented out, won't run oops(); // this one starts up ~oops(); private: int i; }; oops::oops() { i = 0; } oops::~oops() { } boost::thread_specific_ptr<oops> value; I am not assigning to value anywhere. Now when I try to start my programm (I tried only the debug version) my GUI never comes up. When I break into with the debugger I can see, that the programm is sitting somewhere in the main message loop (PumpMessage), but never receiving any messages. When not having the inlined version, behaviour is ok. Any help appreciated. Thank you, Roland

1 0

RE: [Boost-users] boost::shared_ptr inside std::list
by Darryl Green 13 Nov '03

13 Nov '03

> -----Original Message----- > From: James Mastro [mailto:jmastro@rochester.rr.com] > Sent: Thursday, 13 November 2003 11:59 AM > To: Boost Users mailing list > Subject: [Boost-users] boost::shared_ptr inside std::list > > > This one has been driving me nuts all day. In a function I have the > following: > > std::list< boost::shared_ptr<MyObject> > * objectList; An uninitialized pointer to a list of shared pointers to MyObject is probably not what you wanted, but its what you defined. I don't think you bug has anything to do with shared pointers... > > > When debugging my code, the debugger (gdb) dies upon entering the > function with this in it. It says "The Debugger has exited > due to signal > 11 (SIGSEGV).The Debugger has exited due to signal 11 > (SIGSEGV)." My dev > tools felt the need to say it twice for some reason. I pulled this out > and put it in a new project all by itself with the same result. > > If I make it not be a pointer, like this: > > std::list< boost::shared_ptr<MyObject> > objectList; > > then there's no problem. Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

2 1

RE: [Boost-users] Re: travelling salesman for BGL ?
by Ben Hutchings 13 Nov '03

13 Nov '03

Dave <better_cs_now(a)yahoo.com> wrote: > You'll be a millionaire (literally!) if you figure out the exact > solution to TSP in an efficient manner! Only if you patent it as a "business method".

1 0

Building Regex++ lib on Pocket PC using Embedded VC++4.0
by Reuti＠sdc.canon.co.in 13 Nov '03

13 Nov '03

Has anyone tried building regex++ lib for PPC using EVC++? I can build it using VC++6.0 using the .mak files supplied with it.But I am getting errors and warnings. Error is regarding the use of typename keyword in lib source and warning is about C++ Exceptions unwinding capability. I replaced C++ try, catch by Win32 __try , __except but don't know what to do with template error? Can anybody help in this? Also can it be confirmed that its possible to port it on Win CE? Thanx in advance. Reuti

2 1

travelling salesman for BGL ?
by Philippe Guglielmetti 13 Nov '03

13 Nov '03

I'm looking for a free "travelling salesman problem" solver. Does anyone know if something exists for the Boost Graph Library ? I found nothing in the book... Is anybody interested in porting existing code, for example http://www.math.princeton.edu/tsp/concorde.html on BGL ? -- Philippe Guglielmetti - www.dynabits.com

3 2

Re: [Boost-users] graph: Min Spanning Tree (advanced start)
by Jeremy Siek 13 Nov '03

13 Nov '03

Hi Matthew, Yes, that is, as long as that initial list of edges forms a tree. Here's my guess as how to do it for prim's minimum spanning tree. You'll have to directly call breadth_first_visit, redoing all the initialization work done in dijkstra and prim (prim calls dijkstra, which then calls bfs). You'll need to initialize the predecessor map to reflect the starting tree, and also you'll want to set the color of the nodes in the starting tree to black. Then you'll have to color the nodes adjacent to nodes in the tree (that aren't in the tree) gray and stick them in the priority queue... that is, all except for one of the nodes adjacent to the tree (pick an arbitrary one). That node will be your starting node for the bfs. In you're using Kruskal's it is a different story... I'll look at that later if you need it. Cheers, Jeremy On Wednesday, November 12, 2003, at 11:24 AM, Matthew Galati wrote: > Is there a way to give an advanced start to solve Min Spanning Tree > using boost/graph? That is, I have a list of edges in my graph that > must be in the Min Spanning Tree (i.e., their cost is -M, for very big > M). > > Since algorithms for MST are greedy, I assume this can be done - but > is their an easy way to interface to boost/graph's MST algorithms? > > Thanks for any help. > Matt > > -- > Matthew Galati > ISE Lehigh University > IBM Service Parts Solutions > 610.758.4042 (Office) > 610.882.0779 (Home) > magh(a)lehigh.edu, magal11(a)us.ibm.com > http://sagan.ie.lehigh.edu/mgalati/ > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

boost::shared_ptr inside std::list
by James Mastro 13 Nov '03

13 Nov '03

This one has been driving me nuts all day. In a function I have the following: std::list< boost::shared_ptr<MyObject> > * objectList; When debugging my code, the debugger (gdb) dies upon entering the function with this in it. It says "The Debugger has exited due to signal 11 (SIGSEGV).The Debugger has exited due to signal 11 (SIGSEGV)." My dev tools felt the need to say it twice for some reason. I pulled this out and put it in a new project all by itself with the same result. If I make it not be a pointer, like this: std::list< boost::shared_ptr<MyObject> > objectList; then there's no problem. Oddly, both versions of the code work fine when run normally (not being debugged.) I don't see what's wrong with the first version. Is it OK to put boost shared ptrs in a std::list? Is there something else I'm missing? Or is my dev environment just having problems? -jim

1 0

Re:[Boost-users] graph: Min Spanning Tree (advanced start)
by rlyon＠comgroup.net.au 12 Nov '03

12 Nov '03

It's no longer necessarily a minimum spanning tree. The exact algorithm will depend upon whether your starting set of edges always is a tree. Regards ... ____________________Reply Separator____________________ Subject: [Boost-users] graph: Min Spanning Tree (advanced start) Author: Matthew Galati <magh(a)lehigh.edu> Date: 12/11/2003 11:24 AM Is there a way to give an advanced start to solve Min Spanning Tree using boost/graph? That is, I have a list of edges in my graph that must be in the Min Spanning Tree (i.e., their cost is -M, for very big M). Since algorithms for MST are greedy, I assume this can be done - but is their an easy way to interface to boost/graph's MST algorithms?

1 0

Re: [Boost-users] int64_t error
by Gilad Suberri 12 Nov '03

12 Nov '03

Thanks. It seems that I do not have the file "stdint.h", so in cstdint.hpp, int64_t is defined in the last #else section (that goes with #ifdef BOOST_HAS_STDINT_H). When operators.hpp is included before this file (cstdint.hpp,) int64_t does not get defined at all because this next statement from cstdint.hpp becomes false: # if defined(BOOST_HAS_LONG_LONG) && \ !defined(BOOST_MSVC) && !defined(__BORLANDC__) && \ (!defined(__GLIBCPP__) || defined(_GLIBCPP_USE_LONG_LONG)) && \ (defined(ULLONG_MAX) || defined(ULONG_LONG_MAX) || defined(ULONGLONG_MAX)) When the include statements are switched around int64_t gets defined. This is connected to posix_time_config.h where "boost/date_time/time_duration.hpp" is included before "boost/date_time/time_resolution_traits.hpp", which causes the above problem. I switched the two include statements and I am not running into that compiler error anymore, but I am not sure if that will cause other compiler errrors. Hope some of this made sense, let me know what you think or if I am missing anything. Thanks. Gilad ----- Original Message ----- From: "Jeff Garland" <jeff(a)crystalclearsoftware.com> To: "Boost Users mailing list" <boost-users(a)lists.boost.org> Sent: Wednesday, November 12, 2003 10:10 AM Subject: Re: [Boost-users] int64_t error > On Wed, 12 Nov 2003 08:42:08 -0500, Gilad Suberri wrote > > Hi, I am compiling my projects on Solaris, using the latest version > > of the boost date_time library. All the gregorian examples compile > > and build fine, but when I try to compile posix_time ones I get this > > error: > > > > ...error details snipped... > > The version of gcc is 3.0.2. > > I do not get this compiler error when I use gcc 2.95.3, but I needed > > to use the newer version. > > > > Any ideas? Thanks. > > I suspect that somehow you are not getting boost::int64_t defined. Although > looking at the logic in boost/config I'm not seeing why at the moment -- you > might experiment with trying to make sure boost::int64_t is defined. I won't > have a chance to look until later as I'm running out the door. Bottom line is > it should work with this compiler... > > Jeff > > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 2