- Boost-users - lists.boost.org

RE: Re: [Boost-Users] Re: building threads lib with latest from C VS
by William E. Kempf 12 Feb '03

12 Feb '03

> From: Mark Storer <mstorer(a)cardiff.com> > > >The MS APIs do not give you any means with which to cleanup data > >allocated to TLS, and they recommend you add this in DllMain. > > What can you do in DllMain that you can't do with atexit, or some Loki-like > priority singleton system? Handle destruction of TLS data _at thread termination_. The atexit approach would only clean up the data at program termination, which isn't good enough. From what I recall of Loki, it won't apply here either. William E. Kempf wekempf(a)cox.net

1 0

RE: Re: [Boost-Users] Re: building threads lib with latest from C VS
by Mark Storer 12 Feb '03

12 Feb '03

>The MS APIs do not give you any means with which to cleanup data >allocated to TLS, and they recommend you add this in DllMain. What can you do in DllMain that you can't do with atexit, or some Loki-like priority singleton system? --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard;

2 1

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

11 Feb '03

> From: Michael Hunley <mhunley(a)pocketpurchase.com> > At 09:56 AM 2/11/2003 -0500, you wrote: > >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". > > > > Thanks for clearing that up. > > >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. > > Understand & sympathize. What about people who want to bundle that part > into their own DLL (which is largely what I'm doing)? Does it hurt to > leave the build in and doc it as untested? Short term, probably not. Long term even this won't work. > Also, why would inclusion of > TLS require it to be a DLL? By itself, TLS doesn't require this. However, TLS cleanup *does* require this. (We're still trying to find an alternative, because even this approach to TLS cleanup is fraught with peril.) The MS APIs do not give you any means with which to cleanup data allocated to TLS, and they recommend you add this in DllMain. This is why you have incompatible thread creation routines such as CreateThread, _beginthread(ex) and AfxBeginThread. > It would seem like including TLS could also be > done in a static lib or am I being completely obtuse? TLS, yes, TLS cleanup, no. > On an almost related note, I saw mention of a cooperative cancel policy > from another post of yours. Do you have any ETA on that and any info on > what it will support vs what it won't support? Is that info on the > developer mailing list? It's partially implemented in CVS on a branch named "thread_dev" (though this isn't stable). ETA is hopefully very soon, as the C++ standards meeting looms. William E. Kempf wekempf(a)cox.net

1 0

RE: [Boost-Users] Re: HP, aCC and the standards
by Tom Matelich 11 Feb '03

11 Feb '03

actually I talked with one of the people on the aCC dev team and they are looking into adding boost into their test procedues. > -----Original Message----- > From: dlux42 <dlux(a)spam.sch.bme.hu> [mailto:dlux@spam.sch.bme.hu] > Sent: Monday, February 10, 2003 2:15 PM > To: Boost-Users(a)yahoogroups.com > Subject: [Boost-Users] Re: HP, aCC and the standards > > > > > While many compiler vendors strive to be able to compile boost, > > > is this really a measure of Standard C++ conformance? > > > > A pretty good one. That's why they use it as a test. > > It may be true, but HP won't accept it. We help them a lot if we can > point to a part of the standard and can show an "aCC -E" output and an > "aCC -c" output and say: "this point is badly implemented, because it > is not compiled, although the standard said it should". > > > > > > ------------------------ 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. -----------------------------------------------------------------------

1 0

Re: [Boost-Users] Re: building threads lib with latest from CVS
by Michael Hunley 11 Feb '03

11 Feb '03

At 09:56 AM 2/11/2003 -0500, you wrote: >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". > Thanks for clearing that up. >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. Understand & sympathize. What about people who want to bundle that part into their own DLL (which is largely what I'm doing)? Does it hurt to leave the build in and doc it as untested? Also, why would inclusion of TLS require it to be a DLL? It would seem like including TLS could also be done in a static lib or am I being completely obtuse? On an almost related note, I saw mention of a cooperative cancel policy from another post of yours. Do you have any ETA on that and any info on what it will support vs what it won't support? Is that info on the developer mailing list? thanks again for all your info. michael

1 0

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 11 Feb '03

11 Feb '03

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

4 3