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

Re: [Boost-Users] Re: building threads lib with latest from CVS
by William E. Kempf 11 Feb '03

11 Feb '03

> > From: "hunleyexpress <mhunley(a)pocketpurchase.com>" <mhunley(a)pocketpurchase.com> > Date: 2003/02/10 Mon PM 03:47:57 EST > To: Boost-Users(a)yahoogroups.com > Subject: [Boost-Users] Re: building threads lib with latest from CVS > > > Intentionally removed. In the current library it's easier to deal > with a single build type, and since a DLL is required for TLS usage, > the static build was removed. In the next version of the library, > the implementation is going to have to make use of TLS as well, so > you'll always need a DLL, making it pointless to continue providing > both a static library and the threadmon.dll. > > > > If you mean something other than Transport Layer Security when you > say TLS, disregard the rest of this and just let me know what it > means in boost-ese. Sorry, I forget that some acronyms aren't known by everyone. TLS stands for "thread local storage", also known as TSS or "thread specific storage". > I don't quite understand why the threading lib > depends on TLS. I am only including the threading lib to write > thread handling and don't want or need security aspects (I'm handling > those specifically myself for a custom app). I ultimately need to > bundle all of it into a *very* small DLL (or shared lib on Linux) of > my own and don't want to require a separate boost DLL. Why would you > tie the two together, they seem completely orthoganal. BTW: I have > found it rather easy to have Jam build both. I guess it is just more > headache from a testing standpoint. > I appreciate the info. Testing and development. I compile against 5 compilers, and with both static and dynamic libraries this means compiling 10 variants at a minimum (through in both debug and release and you have 20 variants), which is time consuming. But the real kicker is that boost::thread itself is going to rely on TLS shortly, making it so you'll always need a DLL on the Windows platforms. William E. Kempf wekempf(a)cox.net

1 0

Compiling the BGL-Graphviz library: libbgl-viz.a
by Jeff Holle 11 Feb '03

11 Feb '03

The source code that should be able to produce this library is in directory "boost_1_29_0/libs/graph/src". In running the Makefile, the following error is produced: /bin/mv graphviz_parser.tab.h graphviz_parser.h /bin/mv: cannot stat `graphviz_parser.tab.h': No such file or directory. Does anybody know how to fix this problem?

2 1

boost::function2's copy constructor expensive - why?
by Markus Werle 11 Feb '03

11 Feb '03

Hi! Today's profiling of my code (which massively uses boost::function to collect formulas) showed that boost::function2' copy constructor is called zillions of times. OK, I disabled inlining to get some more details, but this I do not understand. The functors are created, stored in an array and do not get copied again, but rather referenced there. Before I dig in that code: where do those copies come from? Is that the normal behaviour triggered ny operator() or is that a hint that I use them the wrong way? Any experience? At present the boost::function overhead kills my application. Tuning tipps? best regards, Markus

2 5

Support for chain graph
by Matthieu P. 11 Feb '03

11 Feb '03

I am interested in an algorithm in Bayesian Networks which uses chain graph, that is a graph that contains both directed and undirected edges. Since the declaration of the template seem to include one or the other, i am looking for ideas on implementing these graph. Any suggestions? Thanks, Matthieu

1 0

Can shared_ptr release ownership of a pointer without destroy it?
by Black Ice 10 Feb '03

10 Feb '03

As following manner: shared_ptr<Foo> ptr(new Foo()); ... Foo * p = ptr.release(); -- /*******************/ ×ÔÓÉ£šliberty£©ÎÞ·ÇŸÍÊÇÕâÑùÒ»ÖÖ³ÐÅµ£ºÃ¿žöÈËœ«»áµÃµœÒ»ÖÖ±£ÕÏ£¬±£ÕÏÎÒÃÇ¿ÉÒÔÓë ÈšÍþ¡¢¶àÊý¡¢Á÷Ë×Œ°ÓßÂÛµÄÓ°ÏìÏà¿¹ºâ¡£ /*******************/

4 3

Fwd: Re: [Boost-Users] HP, aCC and the standards
by Toon Knapen 10 Feb '03

10 Feb '03

On Tuesday 04 February 2003 17:18, Tom Matelich wrote: > Who is running those tests, and what version of aCC is that? I am. I'm using aCC version 53800 currently installed on an HPUX11i. You might notice on the HP website that the latest release was 53700 so it's newer than new ;-) Nevertheless, conformance is still bad. There were quite some messages on the boost-ml on the support for HP recently. > > -----Original Message----- > > From: Toon Knapen [mailto:toon.knapen@si-lab.org] > > Sent: Tuesday, February 04, 2003 12:15 AM > > To: Boost-Users(a)yahoogroups.com > > Subject: Re: [Boost-Users] HP, aCC and the standards > > > > On Monday 03 February 2003 18:06, Tom Matelich wrote: > > > I would recommend contacting the aCC support people. They > > > > are generally > > > > > quite reasonable. In fact, the hp status tables (which > > > > appear a bit out of > > > > > date) at http://www.boost.org/status/cs-hpux.html are run > > > > remotely on a box > > > > > provided by HP for boost to use. > > > > For an updated status-page, check out : > > http://boost.sourceforge.net/regression-logs/ > > and you see that aCC has the highest failure rate ! > > I also recently talked to an HP representative and he was > > under the impression > > that aCC was very confirming. > > > > ------------------------ Yahoo! Groups Sponsor > > ---------------------~--> > > Get 128 Bit SSL Encryption! > > http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA/EbFolB/TM > > -------------------------------------------------------------- > > -------~-> > > > > Info: <http://www.boost.org> > > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> > > > > > > Your use of Yahoo! Groups is subject to > > http://docs.yahoo.com/info/terms/ > > ----------------------------------------------------------------------- > DISCLAIMER: Information contained in this message and/or > attachment(s) may contain confidential information of Zetec, Inc. > If you have received this transmission in error, please notify > the sender by return email. > ----------------------------------------------------------------------- > > > Info: <http://www.boost.org> > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ -------------------------------------------------------

4 3

Re: [Boost-Users] building threads lib with latest from CVS
by William E. Kempf 10 Feb '03

10 Feb '03

> > From: "hunleyexpress <mhunley(a)pocketpurchase.com>" <mhunley(a)pocketpurchase.com> > Date: 2003/02/10 Mon PM 02:07:11 EST > To: Boost-Users(a)yahoogroups.com > Subject: [Boost-Users] building threads lib with latest from CVS > > I am fairly new to boost (and jamfiles). I am using the threads > library for cross platform thread support. Under the stable build a > library libboost_thread.lib is created to staticly link in to my > project, with seperate libs if I am using the DLL STL or static STL. > > That build config is gone in the latest version under CVS, replaced > by a boost_thread dll set up. I want (and need) the old static > version. I have successfully added it back into the jam file so that > all 3 (including the threadmon) are built now, but that isn't > something I really want to have to maintain as I get updates. Is the > static lib intentionally and permanently removed or is it an > oversight/temporary change? Intentionally removed. In the current library it's easier to deal with a single build type, and since a DLL is required for TLS usage, the static build was removed. In the next version of the library, the implementation is going to have to make use of TLS as well, so you'll always need a DLL, making it pointless to continue providing both a static library and the threadmon.dll. William E. Kempf wekempf(a)cox.net

2 1

building threads lib with latest from CVS
by hunleyexpress <mhunley＠pocketpurchase.com> 10 Feb '03

10 Feb '03

I am fairly new to boost (and jamfiles). I am using the threads library for cross platform thread support. Under the stable build a library libboost_thread.lib is created to staticly link in to my project, with seperate libs if I am using the DLL STL or static STL. That build config is gone in the latest version under CVS, replaced by a boost_thread dll set up. I want (and need) the old static version. I have successfully added it back into the jam file so that all 3 (including the threadmon) are built now, but that isn't something I really want to have to maintain as I get updates. Is the static lib intentionally and permanently removed or is it an oversight/temporary change? thanks.

1 0

BGL: cycles in undirected graph
by Tarjei Knapstad 10 Feb '03

10 Feb '03

(Disclaimer: My knowledge of graph theory isn't too broad, so have me excused if this is completely trivial...) I'm struggling a bit with finding cycles in an undirected graph. Doing a DFS/BFS and recording back edges, thus detecting the number of cycles and a connected vertex pair for each one is simple enough. However, I'd also like to find the sequence(s) of vertices that make up the cycle. There's and example in the book that does this, but relies on a graph with direction in the second step where a DFS is done from both back-edge vertices and the results intersected. This won't work in the case of an undirected graph as every vertex is reachable from any other (if there's only one "connected component"), so I would just end up with the complete set of vertices in every case. My idea is to use BFS and the record_predecessors visitor, but I can't seem to wrap my head around how to find the sequence of vertices connecting the cycle(s) from this. Could anyone offer some pointers? (hopefully not NULL :) ) Regards, -- Tarjei

1 1

bug report: boost::tokenizer with VC6
by Navi Singh 09 Feb '03

09 Feb '03

The boost release 1.28.0 of the tokenizer library has the following problem: There are 5 examples, namely, simple_example_1.cpp thru simple_example_5.cpp If I change the main() in each of the 5 to to main1() thru main5() and return 0; the vc60 compiler generates an internal compiler error when parsing the file boost\iterator_adapters.hpp on line 869, where it is parsing the following lines: reference operator*() const { return policies().dereference(*this); }

3 2