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

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