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

How to connect arbitrary memeber function in boost::signals?
by yjwang_bj <yjwang_bj＠yahoo.com> 18 Feb '03

18 Feb '03

Hi, all. I'm working in a project that need loosely coupling. I find boost::signals is perfect for that, save one exception. My question is that I want to connect arbitrary member function to signal. How to do it? Thanks in advanc. Yujiang Wang Feb. 15th, 2003

3 3

RE: [Boost-Users] Re: How to connect arbitrary memeber function i n boost::signals?
by Tom Matelich 18 Feb '03

18 Feb '03

#define myslot(obj, mem) boost::bind(mem, obj, _1) > -----Original Message----- > From: yjwang_bj <yjwang_bj(a)yahoo.com> [mailto:yjwang_bj@yahoo.com] > Sent: Tuesday, February 18, 2003 9:05 AM > To: Boost-Users(a)yahoogroups.com > Subject: [Boost-Users] Re: How to connect arbitrary memeber > function in > boost::signals? > > > > Use the Bind or Lambda library. An example: > > > > class X { > > public: > > void foo(int); > > }; > > > > X* x; > > boost::signal<void (int)> sig; > > > > // So the signal will call x->foo(y) when sig(y) is called: > > sig.connect(boost::bind(&X::foo, x, _1)); > > > > Doug > > It works but with the unusual C++ syntax. In libsigc++, I can do like > this: > sig1.connect(slot(x, &X::foo)); > > Hope boost has something like this though the boost's way is more > powerful. > > Thanks a lot, doug. > > Yujiang Wang > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Get 128 Bit SSL Encryption! > http://us.click.yahoo.com/FpY02D/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

Is there a library for Set/Reset events?
by Russell Hind 18 Feb '03

18 Feb '03

I have just started using the boost::threads library (and associated mutexes). I wondered if there was, or is in progress, a library for set/reset event synchronisation objects or are there plans to add these to the boost::threads library? Cheers Russell

2 2

boost::threads support for Forte6u1/Solaris2.6
by garymmann <gary＠mann.uk.net> 17 Feb '03

17 Feb '03

Firstly, apologies if this is a FAQ. What is the current status of boost::threads on Solaris 2.6 using the Forte 6u1 (5.2) compiler? Is this a "supported" platform/compiler combination. If it "kind of works", are there any known issues which I will need to code around, or is it completely broken. Is the issue with the Solaris pthreads or with the broken compiler? Does the compiler work well enough to be able to compile just the threads module. I'm looking for a threading abstraction portable to at least GCC/Linux, MSVC/Win32 and Forte/Solaris. Is boost::threads likely to be able to satisfy this requirement right now, or am I going to have to look elsewhere. If I do need to look elsewhere, can anyone recommend an alternative to paying large amounts of money away to Rogue Wave! Hope someone can help, regards, Gary

1 0

problem with induced subgraphs
by David Minor <david-m＠orbotech.com> 17 Feb '03

17 Feb '03

I'm using an edge visitor to create subgraphs. I do a simple sub_graph = myGraph.create_subgraphs(), to create a subgraph and then I add vertices using add_vertex(vertex,sub_graph). The vertices are added but the corresponding edges are not. My basic typedefs are: ////////// typedef boost::property<boost::edge_index_t, int> Tmp; typedef boost::property<boost::edge_info_t, GES_EdgeInfo, Tmp> GES_EdgeProperty; typedef boost::property<boost::vertex_color_t, int> Tmp2; typedef boost::property<boost::vertex_self_t, SYS_String, Tmp2> Tmp3; typedef boost::property<boost::vertex_name_t, SYS_String, Tmp3> GES_VertexProperty; typedef boost::adjacency_list< boost::vecS, boost::vecS ,boost::directedS ,GES_VertexProperty ,GES_EdgeProperty> GES_AdjacencyList; typedef boost::subgraph<GES_AdjacencyList> GES_RTGraph; ////////// That is, the graph type is the same as the sub-graph type, which I think is right? Does anybody have any idea why the edges aren't being transferred to the sub-graph?

1 0

Why scoped_ptr dost provide custom deallocation?
by Black Ice 17 Feb '03

17 Feb '03

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

4 7

covariance of shared_ptr types
by Vaclav Vesely 16 Feb '03

16 Feb '03

Hi, in C++ it's possible to write this: class A {}; class B: public A {}; class X { virtual A* f() { ... }; }; class Y: public X { virtual B* f() { ... }; // B* is covariant from A* }; However it is NOT possible to write that with shared_ptr: class X { shared_ptr<A> f() { ... }; }; class Y: public X { virtual shared_ptr<B> f() { ... }; // Error: shared_ptr<B> is NOT covariant from shared_ptr<A> }; I don't know C++ standard very well (in fact I've never read it). So my question is: it's possible to adjust shared_ptr to allow such constructions? Thank you, Wasek [Non-text portions of this message have been removed]

3 3

Problems building RegExp3
by kekogomez <kekogomez＠yahoo.es> 15 Feb '03

15 Feb '03

Hello to all, I have tried to build the RegExp3 library... but I get some errors... I'm using Vc++ Net. I execute the command nmake vc7.mak and I get the nexts error results... could someone help me? .... .... .... link kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /incremental:yes /pdb:"vc7/boost_regex_vc7_m did.pdb" /debug /machine:I386 /out:"vc7/boost_regex_vc7_mdid.dll" /imp lib:"vc7/boost_regex_vc7_mdid.lib" /LIBPATH:\lib vc7/boost_regex_vc7_mdid/c_regex_traits.obj vc7/boost_regex_vc7_mdid/c_regex_traits_common.obj vc7/boost_regex_vc7_mdid/cpp_regex_traits.obj vc7/boost_regex_vc7_mdid/cregex.obj vc7/boost_regex_vc7_mdid/fileiter.obj vc7/boost_regex_vc7_mdid/instances.obj vc7/boost_regex_vc7_mdid/posix_api.obj vc7/boost_regex_vc7_mdid/regex.obj vc7/boost_regex_vc7_mdid/regex_debug.obj vc7/boost_regex_vc7_mdid/regex_synch.obj vc7/boost_regex_vc7_mdid/w32_regex_traits.obj vc7/boost_regex_vc7_mdid/wide_posix_api.obj vc7/boost_regex_vc7_mdid/winstances.obj Creating library vc7/boost_regex_vc7_mdid.lib and object vc7/boost_regex_vc7_mdid.exp regex_synch.obj : error LNK2001: unresolved external symbol __RTC_CheckEsp w32_regex_traits.obj : error LNK2001: unresolved external symbol __RTC_CheckEsp wide_posix_api.obj : error LNK2019: unresolved external symbol __RTC_CheckEsp referenced in function _regerrorW@16 winstances.obj : error LNK2001: unresolved external symbol __RTC_CheckEsp fileiter.obj : error LNK2001: unresolved external symbol __RTC_CheckEsp instances.obj : error LNK2001: unresolved external symbol __RTC_CheckEsp posix_api.obj : error LNK2019: unresolved external symbol __RTC_CheckEsp referenced in function _regerrorA@16 regex.obj : error LNK2019: unresolved external symbol __RTC_CheckEsp referenced in function "public: __thiscall boost::match_results<char const *,class boost::detail::allocator_adapter<char,class boost::detail::simple_alloc> >::match_results<char const *,class boost::detail::allocator_adapter<char,class boost::detail::simple_alloc> >(class boost::detail::allocator_adapter<char,class boost::detail::simple_alloc> const &)" (??0?$match_results@PBDV? $allocator_adapter@DVsimple_alloc@detail@boost@@@detail@boost@@@boost@ @QAE@ABV?$allocator_adapter@DVsimple_alloc@detail@boost@@@detail@1@@Z) c_regex_traits.obj : error LNK2019: unresolved external symbol __RTC_CheckEsp referenced in function "unsigned int __cdecl `anonymous namespace'::re_get_message(unsigned short *,unsigned int,unsigned int)" (?re_get_message@?A0xc953bc5d@@YAIPAGII@Z) c_regex_traits_common.obj : error LNK2001: unresolved external symbol __RTC_CheckEsp cpp_regex_traits.obj : error LNK2001: unresolved external symbol __RTC_CheckEsp cregex.obj : error LNK2001: unresolved external symbol __RTC_CheckEsp regex_synch.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 w32_regex_traits.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 wide_posix_api.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 winstances.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 fileiter.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 instances.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 posix_api.obj : error LNK2019: unresolved external symbol @_RTC_CheckStackVars@8 referenced in function _regerrorA@16 regex.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 c_regex_traits.obj : error LNK2019: unresolved external symbol @_RTC_CheckStackVars@8 referenced in function "unsigned int __cdecl `anonymous namespace'::re_get_message(unsigned short *,unsigned int,unsigned int)" (?re_get_message@?A0xc953bc5d@@YAIPAGII@Z) c_regex_traits_common.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 cpp_regex_traits.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 cregex.obj : error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8 regex_synch.obj : error LNK2001: unresolved external symbol __RTC_Shutdown w32_regex_traits.obj : error LNK2001: unresolved external symbol __RTC_Shutdown wide_posix_api.obj : error LNK2001: unresolved external symbol __RTC_Shutdown winstances.obj : error LNK2001: unresolved external symbol __RTC_Shutdown fileiter.obj : error LNK2001: unresolved external symbol __RTC_Shutdown instances.obj : error LNK2001: unresolved external symbol __RTC_Shutdown posix_api.obj : error LNK2019: unresolved external symbol __RTC_Shutdown referenced in function _regerrorA@16 regex.obj : error LNK2001: unresolved external symbol __RTC_Shutdown c_regex_traits.obj : error LNK2001: unresolved external symbol __RTC_Shutdown c_regex_traits_common.obj : error LNK2001: unresolved external symbol __RTC_Shutdown cpp_regex_traits.obj : error LNK2019: unresolved external symbol __RTC_Shutdown referenced in function "public: __thiscall boost::re_detail::message_data<char>::message_data<char>(class std::locale const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0? $message_data@D@re_detail@boost@@QAE@ABVlocale@std@@ABV? $basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@4@@Z) cregex.obj : error LNK2001: unresolved external symbol __RTC_Shutdown regex_synch.obj : error LNK2001: unresolved external symbol __RTC_InitBase w32_regex_traits.obj : error LNK2001: unresolved external symbol __RTC_InitBase wide_posix_api.obj : error LNK2019: unresolved external symbol __RTC_InitBase referenced in function _regerrorW@16 winstances.obj : error LNK2001: unresolved external symbol __RTC_InitBase fileiter.obj : error LNK2001: unresolved external symbol __RTC_InitBase instances.obj : error LNK2001: unresolved external symbol __RTC_InitBase posix_api.obj : error LNK2001: unresolved external symbol __RTC_InitBase regex.obj : error LNK2001: unresolved external symbol __RTC_InitBase c_regex_traits.obj : error LNK2001: unresolved external symbol __RTC_InitBase c_regex_traits_common.obj : error LNK2001: unresolved external symbol __RTC_InitBase cpp_regex_traits.obj : error LNK2019: unresolved external symbol __RTC_InitBase referenced in function "public: __thiscall boost::re_detail::message_data<char>::message_data<char>(class std::locale const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0? $message_data@D@re_detail@boost@@QAE@ABVlocale@std@@ABV? $basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@4@@Z) cregex.obj : error LNK2001: unresolved external symbol __RTC_InitBase vc7/boost_regex_vc7_mdid.dll : fatal error LNK1120: 4 unresolved externals

2 1

boost::thread and MinGW
by Russ 14 Feb '03

14 Feb '03

Hi, I was previously using the threading library with MinGW (latest release version) with no problems. Yesterday I came across a segfault that occurred when accessing a shared pointer so I updated the boost-cvs version I was using to see if it was a known problem that had been fixed; however when attempting to build the new version it appeared that threading had been disabled for MinGW? Is this the case or is it a problem with the way I'm building my code. Any help greatly appreciated, Russ

3 3

RE: [Boost-Users] Re: Why scoped_ptr dost provide custom dealloca tion?
by bjorn.karlsson＠readsoft.com 14 Feb '03

14 Feb '03

> From: Peter Dimov [mailto:pdimov@mmltd.net] [snip] > A zero-overhead scoped_ptr<X, D> would require a helper class here: Yes, and I shouldn't have said scoped_ptr<X,D>, but scoped_ptr<X> with custom deallocation capabilities... I'd be willing to pay for the increase in size, but I realize not everyone would. The case is real, however. > scoped_ptr<void, void (*) (void *)> p(hPrinter, &ClosePrinter); > > that would increase sizeof(scoped_ptr) and is of questionable > utility. :-) Actually, I kind of like it. :-) > There is always the option to define a dedicated printer > class, of course. Yep, but there are hundreds of cases like this, which is why the feature would be useful. One could argue the same for the resource management of any type, right? ;-) Bjorn Karlsson

1 0

RE: [Boost-Users] Re: Why scoped_ptr dost provide custom dealloca tion?
by bjorn.karlsson＠readsoft.com 14 Feb '03

14 Feb '03

> From: Peter Dimov [mailto:pdimov@mmltd.net] [snip] > (An example of a convincing case: "In my project I have > encountered the > following situation: <description with real(istic sounding) > identifiers> and > I believe that scoped_ptr<X, D> would be a perfect fit." Some > non-examples: > "Someone might find it useful." "Wouldn't it be cool if...") In my project I have encountered the following situation: A lot of the code needs to handle (no pun intended) resources that are represented by indiscriminate types, such as void* or long. Different resources (and different functions for allocation/deallocation) use this handle type, so specialization is not an option. It's possible to use shared_ptr to handle lifetime management of the resource: HANDLE hPrinter=0; OpenPrinter(_T("Some printer"),&hPrinter,0); if (boost::shared_ptr<void> p(hPrinter,&ClosePrinter)) { } While this works, it doesn't convey the intent of the code (nor preserve it): the resource should typically not be shared, only scoped, and I believe that scoped_ptr<X,D> would be a perfect fit. There are other tools in Boost (outside too, of course) for solving this type of problem, but I think it would be more than cool for scoped_ptr to have this feature; I'd definitely use it in real code. Bjorn Karlsson

2 1

[BGL] Strange result with internal graph properties
by yg-boost-users＠m.gmane.org 13 Feb '03

13 Feb '03

I have the following code in one of my header files: struct vertex_type_t { typedef boost::vertex_property_tag kind; }; enum vtype { ROOT, INNER, LEAF }; typedef boost::property<vertex_type_t, enum vtype> vertex_type; typedef boost::property<boost::vertex_index_t, int, vertex_type> vertex_index; typedef boost::property<boost::vertex_name_t, std::string, vertex_type> vertex_property; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, vertex_property, edge_property> tree; Notice the error: The vertex properties are not chained together. Rather, the actual vertex property that is added to the graph points to vertex_type, and the vertex_index /also/ points to the vertex_type! Now the strange thing: I have been running this and using all of the vertex properties, including vertex_index, without any problems, but when I noticed this, and tried setting the last template parameter of vertex_property to vertex_index instead I get segmentation faults. I have no idea why this is. Björn

1 1

regex_match() Division By Zero
by Glover Barker 13 Feb '03

13 Feb '03

I am using boost::regex (1.29.0) under MSVC++ 6.0. Whenever I call regex_match(), I get: "Unhandled exception in filename.exe: 0xC0000094: Integer Divide by Zero." I have tried various ways to make the call (including the snippets posted on www.boost.org) Even this simple example fails: regex expression("abc"); cmatch what; if ( regex_match("xyz", what, expression) ) { // Whatever ... } Breakpoints reveal that after expression is set, the value of _expression_len is still 0. So when regex_match() is called, it in turn sends the value of expression.size() (which is just _expression_len) to re_detail::_priv_match_data(), which sends this value to estimate_max_state_count(). Then estimate_max_state_counts(), which calls this value "states", does the following: states *= states; // and later ... if(dist > (difference_type)(lim / states)) Since states is 0, this last expression causes division by 0, and the resulting exception. In case my environment matters, I am building my program under MSVC++ 6.0, running with boost_regex.dll. I am defining BOOST_REGEX_NO_LIB and BOOST_REGEX_USE_CPP_LOCALE, and linking in boost_regex.lib. What am I doing wrong? Glover Barker

2 1

Compile problem with regex.hpp and VS6SP5
by soulofsealion <dworthem＠symyx.com> 13 Feb '03

13 Feb '03

When I included regex.hpp into my project: #include <boost\regex.hpp> I received the following errors c:\cvsprojectsroot\renaissance\3rdpartyfiles\boostlibrary\boost\regex. hpp(860) : error C2899: typename cannot be used outside a template declaration c:\cvsprojectsroot\renaissance\3rdpartyfiles\boostlibrary\boost\regex. hpp(440) : error C2899: typename cannot be used outside a template declaration So at lines 440-2 template <class iterator, class Allocator = #if !(defined(BOOST_MSVC) && (BOOST_MSVC <= 1300)) BOOST_DEFAULT_ALLOCATOR(typename re_detail::def_alloc_param_traits<iterator>::type) > I Tried the following: //This section was altered to handle the problem of the VS6 compiler not handling of a typename in a macro for a template parameter-DWW 02/06/2003 template<class iterator> class def_alloc_param_traits_fixclass { public: typedef typename re_detail::def_alloc_param_traits<iterator>::type def_alloc_param_traits_fix; }; template <class iterator, class Allocator = #if !(defined(BOOST_MSVC) && (BOOST_MSVC <= 1300)) //BOOST_DEFAULT_ALLOCATOR(typename re_detail::def_alloc_param_traits<iterator>::type) > BOOST_DEFAULT_ALLOCATOR (def_alloc_param_traits_fixclass<iterator>::def_alloc_param_traits_fix ) > //End of section altered to handle the problem of the VS6 compiler not handling of a typename in a macro for a template parameter-DWW 02/06/2003 And at lines 858-862 namespace re_detail{ template <class iterator, class Allocator = BOOST_DEFAULT_ALLOCATOR (typename def_alloc_param_traits<iterator>::type) > class match_results_base { I tried: namespace re_detail{ //This section was altered to handle the problem of the VS6 compiler not handling of a typename in a macro for a template parameter-DWW 02/06/2003 template<class iterator> class def_alloc_fixclass { public: typedef typename def_alloc_param_traits<iterator>::type def_alloc_fix; }; //template <class iterator, class Allocator = BOOST_DEFAULT_ALLOCATOR (typename def_alloc_param_traits<iterator>::type) > template <class iterator, class Allocator = BOOST_DEFAULT_ALLOCATOR(def_alloc_fixclass<iterator>::def_alloc_fix) > //End of section altered to handle the problem of the VS6 compiler not handling of a typename in a macro for a template parameter-DWW 02/06/2003 class match_results_base { This compiled OK, has any one else had this problem and any comments on this fix or is there anything else that I missed so I do nto have to change the regex.hpp file? it appeared to me that the VS6 compile has a problem with a typename as a parameter in a macro that is in turn a template parameter. Thank you for any help.

3 2

Ah.......Boost Socket.....
by hjlee＠hurim.net 12 Feb '03

12 Feb '03

Anyone who knows when boost socket library is comming and where I can get beta version..? [Non-text portions of this message have been removed]

2 1

boost::bind/function and C function pointers
by Thomas Pollinger 12 Feb '03

12 Feb '03

Apologies if this topic has already been discussed. I have looked around on various mailing lists, in addition I have tried to make it work with the current C++ STL standard with std::mem_fun and std::bind1st but with no success. The problem is basically to bind a member function pointer with an instance of its declaring class and to assign the result to an existing C library function that expects a C style function pointer. This certainly works for ordinary C functions and static C++ functions, however fails for bound member function pointers. Here is what I am trying to achieve: #include <boost/bind.hpp> // C function declared in some library struct E; extern void setCallBack(void (*callback_fct)(E*)); class A { public: void init(); void callBack(E *e); .... }; void A::init() {setCallBack(boost::bind(&A::callBack, this));} void A::callBack(E *e) {...} I tried also using the STL calls, but without success either: ... setCallBack(std::bind1st(std::mem_fun(&A::callBack), this)); I like the elegant approach of boost::bind and would like to use it for this case. The workaround would be to declare a static function and to store the instance somewhere to access the other members of the A instance - but I'd prefer the other way if there is a solution to make it work. BTW, I am using gcc v 3.2 on Linux/i386 - but I guess that this is a more general problem than a specific compiler issue. The error I've gotten is /opt/src/boost/boost/bind.hpp: In instantiation of `boost::_bi::result_traits<boost::_bi::unspecified, void (A::*)(E*)>': /opt/src/boost/boost/bind/bind_template.hpp:16: instantiated from `boost::_bi::bind_t<boost::_bi::unspecified, void (A::*)(E*), boost::_bi::list1<boost::_bi::value<A*> > >' controller.cpp:28: instantiated from here /opt/src/boost/boost/bind.hpp:59: `void (A::*)(E*)' is not a class, struct, or union type Chaning boost::bind(...) to boost::bind<void>(...) to explicitly delclare the return type yields: controller.cpp:28: cannot convert `boost::_bi::bind_t<void, void (A::*)(E*), boost::_bi::list1<boost::_bi::value<A*> > >' to `void (*)(E*)' for argument `1' to `void setCallBack(void (*)(E*))' which probably reveals the root of the problem, that of not being able to cast a boost function pointer type to a regular C function type. I tried applying some cast operators, but that failed already in the syntactical stage of the parser, e.g. static_cast<void (*)(E*)>. -Thomas

2 5

up-to-date documentation dor boost.python
by Pierre Barbier de Reuille 12 Feb '03

12 Feb '03

Hi ! I'm totally new with boost.python and I need to use some tool to wrap C++ code into python interpreter. The problem I have is that, apparently, the tutorial given with boost.python does not reflect the current implementation. Is there any way to have an up to date tutorial or an organized list of the modifications I can refer to when looking at the tutorial ? Thanks, -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68

1 0

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

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

11 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