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

Compiling smart_ptr library
by l＠lo 08 May '03

08 May '03

Hi everybody! I'm trying to compile the smart_ptr library using the Jamfile in the test directory. Some of the test *.cpp files are compiled successfully, but some of them drops the following error: sunpro-Link-action ../../../libs/smart_ptr/test/bin/shared_ptr_alloc_ test.test/sunpro/debug/runtime-link-dynamic/shared_ptr_alloc_test Undefined first referenced symbol in file boost::__RTTI__1nFboostPchecked_deleter4nBZ___ /rest/proj/users/kercsoj/boost/boost_1_30_0/libs/s mart_ptr/test/bin/shared_ptr_alloc_test.test/sunpr o/debug/runtime-link-dynamic/ SunWS_cache/CC_obj__/_iANwWXwaw2nbnjBybyL.o [Hint: static member boost::__RTTI__1nFboostPchecked_deleter4nBZ___ must be defined in the program] It's seems, it is a common error, because it appears several times in the error output of the compiler. Has anybody any ideea, why this error message comes, and how could be corrected? Thanks, lalo

4 5

Indirect Iterator Adaptor, std::set and MSVC 6.5
by Joaquín Mª López Muñoz 08 May '03

08 May '03

The following produces an internal compiler crash in MSVC 6.5 #include <set> #include <boost/iterator_adaptors.hpp> int main() { typedef std::set<int *> type0; typedef boost::indirect_iterator_generator< type0::iterator,const int>::type type1; type0 s; type1 it(s.begin()); return 0; } This happens for std::set only, using say std::vector instead works fine. Is some workaround known? TIA Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Regex issue under Visual Studio 2003
by Frank Schwab 08 May '03

08 May '03

I have an inherited VC++ program that I am trying to port to Microsoft Visual Studio 2003 (it compiles and runs fine in Visual Studio 6.0). I've downloaded the 1.30.0 release, and the following problem still occurs. The (exceptionally) verbose error message I receive from the compiler is: error C2664: 'bool boost::regex_match<std::char_traits<char>,std::allocator<_Ty>,Allocator,char ,boost::regex_traits<charT>,std::allocator<_Ty>>(const std::basic_string<_Elem,_Traits,_Ax> &,boost::match_results<iterator,Allocator> &,const boost::reg_expression<charT,traits,Allocator> &,unsigned int)' : cannot convert parameter 2 from 'boost::cmatch' to 'boost::match_results<iterator,Allocator> &' with [ _Ty=char, Allocator=std::allocator<char>, charT=char, _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char>, iterator=std::basic_string<char,std::char_traits<char>,std::allocator<char>> ::const_iterator, traits=boost::regex_traits<char> ] and [ iterator=std::basic_string<char,std::char_traits<char>,std::allocator<char>> ::const_iterator, Allocator=std::allocator<char> ] The Code fragment I get the error on is: // lpcszDeviceName is a function parameter defined as LPCTSTR lpcszDeviceName TSTRING strName = lpcszDeviceName; boost::regex expr("IW\\s+[A-Za-z]+\\s+([0-9]+)"); boost::cmatch matches; if (boost::regex_match(strName, matches, expr)) { ... } with the error message pointing to: if (boost::regex_match(strName, matches, expr)) This may be related to a Microsoft note: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html /vclrfsomeiteratorsarenolongersameaspointers.asp but, then again, it may not. Anyone have any suggestions? I am well out of my depth in trying to understand the incantations here, and have a dozen spots in the code where this occurs. TIA, /frank

2 1

call_traits and MSVC 7.1
by Randy Bowen 08 May '03

08 May '03

We have been using call_traits from Boost version 1.29.0 in conjunction with MSVC 7.0. When attempting to recompile this code under MSVC 7.1, using either Boost 1.29.0 or 1.30.0, we now encounter compilation errors. A simple example of the usage pattern is: ############################################################### #include <boost/call_traits.hpp> class A { public: template<typename _Source> void doSomething ( typename boost::call_traits<_Source>::param_type value ) { } }; class B { public: explicit B(double d = 1.0, int i = 42) : _d(d), _i(i) {} B(B const& b) : _d(b._d), _i(b._i) {} private: double _d; int _i; }; extern "C" int main(int argc, char* argv[]) { A a; B b; a.doSomething(b); return 0; } ############################################################# The new compiler generates the error message: c:\Documents and Settings\rbowen\My Documents\Projects\CallTraitsTest\CallTraitsTest.cpp(34) : error C2783: 'void A::doSomething (boost::call_traits<_Source>::param_type)' : could not deduce template argument for '_Source' c:\Documents and Settings\rbowen\My Documents\Projects\CallTraitsTest\CallTraitsTest.cpp(11) : see declaration of 'A::doSomething' As an experiment, I manually included the older logic for call_traits by cutting and pasting the relevant classes into my source from 'detail/ob_call_traits.hpp' and still encountered the same error. Has anyone else experienced this? Is this (yet another) MS compiler bug?

2 1

Static thread library missing in 1_30_0
by yss15632 08 May '03

08 May '03

Hi, I am using boost on a linux system. I upgraded from boost_1_29_0 to 1_30_0. However, if I build the library just by typing "bjam" I cannot find the static library libboost_thread.a, in contrary to version 1_29_0. How can I generate it? Thank you very much, Stefan

3 2

date_time link or compile problem
by Jimmy Pritts 08 May '03

08 May '03

I have boost 1.29 and gcc 3.2.2 on Linux. Here is the simple code I am trying to compile: #include <string> #include "boost/date_time/gregorian/gregorian.hpp" int main() { using namespace std; using namespace boost::gregorian; string ds("2002/1/25"); date d1(from_string(ds)); return 0; } I get the following link error: make g++ main.cc -lstdc++ -o test /tmp/ccph1inq.o(.gnu.linkonce.t._ZN5boost9date_time4dateINS_9gregorian4dateENS2_18gregorian_calendarENS0_13date_durationIlEEEC2ERKNS0_19year_month_day_baseINS2_9greg_yearENS2_10greg_monthENS2_8greg_dayEEE+0x11): In function `boost::date_time::date<boost::gregorian::date, boost::gregorian::gregorian_calendar, boost::date_time::date_duration<long> >::date[not-in-charge](boost::date_time::year_month_day_base<boost::gregorian::greg_year, boost::gregorian::greg_month, boost::gregorian::greg_day> const&)': : undefined reference to `boost::date_time::gregorian_calendar_base<boost::date_time::year_month_day_base<boost::gregorian::greg_year, boost::gregorian::greg_month, boost::gregorian::greg_day>, unsigned long>::day_number(boost::date_time::year_month_day_base<boost::gregorian::greg_year, boost::gregorian::greg_month, boost::gregorian::greg_day> const&)' collect2: ld returned 1 exit status make: *** [test] Error 1 The missing symbol does not seem to be in the static library libboost_date_time.a, so I don't think I need to link to that. Any suggestions? Thanks in advance, Jimmy.

2 1

RE: [Boost-Users] call_traits and MSVC 7.1
by Arjun Bijanki 08 May '03

08 May '03

> From: Randy Bowen [mailto:rbowen@stamps.com] > Sent: Wednesday, May 07, 2003 5:46 PM > To: Boost-Users(a)yahoogroups.com > Subject: [Boost-Users] call_traits and MSVC 7.1 > > We have been using call_traits from Boost version 1.29.0 in > conjunction with MSVC 7.0. When attempting to recompile this code > under MSVC 7.1, using either Boost 1.29.0 or 1.30.0, we now > encounter compilation errors. A simple example of the usage pattern > is: <code snipped> This is illegal code. That it compiled in MSVC 7.0 was a bug. The template parameter '_Source' can not be deduced from the callsite of doSomething. 14.8.2.4 in the ISO/IEC 14882 lists the forms in which template parameters can be deduced, but a qualified name involving nested types is not one of them. I suspect it's because of something like this: template<typename T> struct S { typedef T type; }; template<> struct S<char> { typedef int type; }; template<typename T> void foo(typename S<T>::type); int main() { foo(3); //what is T deduced to be? } I'd guess the documentation for call_traits discusses typical usage patterns, and may help. You can also explicitly specify the template argument. Hope this helps. Arjun Bijanki Microsoft Visual C++

1 0

ublas: identity_matrix and row()
by Alexander G Winbow 08 May '03

08 May '03

It seems that identity_matrix does not work with row(); is this supposed to be the case? For example: ----------- code excerpt ----------- #include <boost/numeric/ublas/matrix.hpp> #include <boost/numeric/ublas/vector.hpp> int main () { using namespace boost::numeric::ublas; //matrix<double> im(3,3); // this works identity_matrix<double> im(3); // this does not boost::numeric::ublas::vector<double> v = row(im,1); } ------------------------------------ Using matrix<> im, the code works fine, but using identity_matrix<> im, g++ blows up with four or five errors of the form included below, on lines 529, 61, 100, 104, and 84 of matrix_proxy.hpp. I've got quite a lot of questions on ublas, even after combing through the ublas and boost documentation, wiki, and mailing lists at great length. Is this an appropriate forum to pepper with questions, or is there some other manual I can RTFM first? Thanks, -Alex -------- errors excerpt compiling the above --------- /home/linux/phcomp/ph141w/ph141wam/libraries/boost_1_30_0/boost/numeric/ublas/matrix_proxy.hpp: In instantiation of `boost::numeric::ublas::matrix_row<boost::numeric::ublas::identity_matrix<double> >': rowtest.cpp:10: instantiated from here /home/linux/phcomp/ph141w/ph141wam/libraries/boost_1_30_0/boost/numeric/ublas/matrix_proxy.hpp:529: no type named `closure_type' in `class boost::numeric::ublas::identity_matrix<double>' /home/linux/phcomp/ph141w/ph141wam/libraries/boost_1_30_0/boost/numeric/ublas/matrix_proxy.hpp:529: template argument 3 is invalid -----------------------------------------------------------

2 1

Why isn't the "last access time" part of the filesystem library?
by richard_fanta 07 May '03

07 May '03

Looking at the filesystem library and the attributes work in boost- sandbox, I don't immediately see "last access time" being available for a file or directory. "Last access time" was included in Dietmar Kuehl's original dir_it. Can someone kindly tell me why this was removed? It's highly useful, and part of every filesystem that I've seen. Thanks, Rick

2 2

RegEx Split function dies.
by tfandango 07 May '03

07 May '03

Hi- I am attempting to parse email headers using the boost regex library. I would prefer that each email address in the TO field (delimited by a comma) would be placed into a vector<string>. Currently, I am able to obtain the entire to line (all the to addresses). I can use another regular expression to seperate it out but I'd rather do it all in one. However, If I try to add another more to this I get an exception: "Max regex search depth exceeded." I am assuming that this is because I've created a infinite loop. I'm not sure how to extend this expression to place every email address in the vector seperatly. Thanks here's my code snippet: char * expression_text = //Any possible leading whitespace: "^[ ]*" //The "To" field name in any case: "TO" //Any more whitespace: "[ ]*" //Then a colon: ":" //More white space potentially "[ ]*" //Everything here is an address up to "\r\n"; "([-(a)_\\.\"<>A-Za-z0-9]+),?"; //Create the expression class to use: RegEx expression(expression_text, true); //Attempt to grep the mail_buffer: int num_recv = 0; try { num_recv = expression.Split(to, mail_buffer); } catch (...){ //throw some exception } }

2 2

bjam and windows command line problem.
by Fernando Cacciola 07 May '03

07 May '03

Hi, I'm having a hard time trying to use bjam to build boost 1.29.0. I have Win98 in Spanish, and I use Borland C++ Builder 5.0 (its bcc32.exe corresponds to is BCC5.5.1) I have boost 1.29.0 installed at: "C:\Libraries\boost\Repository\boost" I've downloaded bjam for Microsoft Windows: >bjam -v Boost.Jam Version 3.1.0. OS=NT. Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc. Copyright 2001 David Turner. Copyright 2001-2002 David Abrahams. I've temporarily modified the root 'jamfile' so that it builds only the Test library. and I've done: subst d: "c:\archivos de programa\borland\cbuilder5" set BCCROOT=d: (you'll see why in a moment) If I try: c:\>cd C:\Libraries\boost\Repository\boost" C:\Libraries\boost\Repository\boost> bjam -sTOOLS=borland I receive messages of the form: borland-C++-action libs\test\build\bin\libpem.lib\borland\debug\runtime-link-static\threading-s ingle\execution_monitor.obj "d:\bin\bcc32" -j5 -q -c -P -w -Ve -Vx -a8 -v -Od -vi- -tWC -WM- -w-8001 -I"libs\test\build" -I"C:\Libraries\boost\Repository\boost" -I"d:\includ e" -o"libs\test\build\bin\libpem.lib\borland\debug\runtime-link-static\thre ading-single\execution_moni Error E2266: No file names given tor.obj" "libs\test\build\../src\execution_monitor.cpp" C:\WINDOWS\TEMP\JAMTMP00.BAT [2] Unknown command "TOR.OBJ" "LIBS\TEST\BUILD\.." "d:\bin\bcc32" -j5 -q -c -P -w -Ve -Vx -a8 -v -Od -vi- -tWC -WM- -w-8001 -I"libs\test\build" -I"C:\Libraries\boost\Repository\boost" -I"d:\includ e" -o"libs\test\build\bin\libpem.lib\borland\debug\runtime-link-static\thre ading-single\execution_monitor.obj" "libs\test\build\../src\execution_monitor.cpp" ...failed borland-C++-action libs\test\build\bin\libpem.lib\borland\debug\runtime-link-static\threading-s ingle\execution_monitor.obj... If I'm interpreting this output correctly, the problem is that the command line feed to bcc32 exceeds 256 characters. What can be done about this? Is there a way for 'borland-tools.jam' to put the bcc32 parameters in a tmp response file and use: bcc32.exe @tmprsp.rsp? Any help will be appreciated. TIA, -- Fernando Cacciola

4 22

RE: PP Library...
by Eric Robert 07 May '03

07 May '03

Ok, I see that there are 3 ways of doing this now. What is the recommendation for something small like 2 or 3 lines for each native types i.e. more or less 12 iterations? Eric "Paul Mensonides" <yg-boost-users(a)m.gmane.org> wrote > Tanton Gibbs wrote: > > You can use BOOST_PP_LIST_FOR_EACH > > > > #define ARG_LIST (char, (int, (unsigned int, (long, ...)))) > > #define DO_IT(r, data, elem) void foo( elem ); > > > > BOOST_PP_LIST_FOR_EACH( DO_IT, , ARG_LIST ) > ^ > This empty argument is undefined in C++. In C99, it is allowed and called a > "placemarker." Instead of passing nothing, just pass anything and ignore it. > > // ----- // > > #include <boost/preprocessor/list/for_each.hpp> > > #define ARG_LIST \ > (char, (int, (unsigned, (long, BOOST_PP_NIL)))) \ > /**/ > #define DO_IT(r, ignored, elem) \ > void foo( elem ); \ > /**/ > > BOOST_PP_LIST_FOR_EACH( DO_IT, ?, ARG_LIST ) > > #undef ARG_LIST > #undef DO_IT > > // ----- // > > Note that there are other ways to do this also. For instance, use of > "sequences" makes the definition of ARG_LIST easier: > > // ----- // > > #include <boost/preprocessor/seq/for_each.hpp> > > #define ARGS \ > (char)(int)(unsigned)(long) \ > /**/ > #define DO_IT(r, ignored, elem) \ > void foo( elem ); \ > /**/ > > BOOST_PP_SEQ_FOR_EACH( DO_IT, ?, ARGS ) > > #undef ARGS > #undef DO_IT > > // ----- // > > Of course, if what you want to generate is much larger, you might want to use > some form of vertical repetition: > > // ----- // > > #include <boost/preprocessor/iteration/local.hpp> > #include <boost/preprocessor/seq/elem.hpp> > > #define ARGS \ > (char)(int)(unsigned)(long) \ > /**/ > > #define BOOST_PP_LOCAL_MACRO(n) \ > void foo( BOOST_PP_SEQ_ELEM(n, ARGS) ); \ > /**/ > #define BOOST_PP_LOCAL_LIMITS \ > (0, BOOST_PP_SEQ_SIZE(ARGS) - 1) \ > /**/ > #include BOOST_PP_LOCAL_ITERATE() > > #undef ARGS > > // ----- // > > Regards, > Paul Mensonides [Non-text portions of this message have been removed]

3 8

RE: [Boost-Users] bug in pthreads implementation of recursive_mut ex
by Feldman, Yulik 06 May '03

06 May '03

Thanks Alexander for the pointer to this long and interesting discussion. I'll check my design whether I could get rid of the recursive mutexes in order to reduce the probability of not holding invariants when the wait() is called, especially since the code still doesn't behave correctly, even after the Boost bug is fixed :) William, unfortunately I don't have a small testcase for the bug and it seems that it will be too time-consuming for me to try to prepare a small "working" testcase. Thanks for confirming the bug report (it makes me feel better that the debugging time was not wasted). --Yulik. -----Original Message----- From: William E. Kempf [mailto:wekempf@cox.net] Sent: Monday, May 05, 2003 6:44 PM To: Boost-Users(a)yahoogroups.com Subject: Re: [Boost-Users] bug in pthreads implementation of recursive_mutex Feldman, Yulik said: > Hi, > > > > It looks that there is a bug in > .../boost_1_30_0/libs/thread/src/recursive_mutex.cpp. The bug shows in > the pthreads implementation of the recursive_mutex when the mutex is > used with the "condition" synchronization primitive. Here is the > description of the bug: You're evaluation of the bug is correct. I'll fix this in CVS shortly. Do you maybe have a test case for this that I could add to the regression tests? BTW, Mr. Terekhov does provide a good resource in his posting on this subject. I disagree with some points in the thread he posted, but it is quite true that you absolutely must gaurantee that invariants hold at the point cond.wait() is called, and that doing so is complicated by the use of recursive locks. Either avoid recursive locks entirely, avoid condition variables with recursive mutexes, or be very sure of the design and the state of your invariants. -- William E. Kempf 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/

2 1

Problems with mpl::push_back
by joaquintides 06 May '03

06 May '03

#include <boost/mpl/list.hpp> #include <boost/mpl/push_back.hpp> int main() { typedef boost::mpl::list<> type0; typedef boost::mpl::push_back<type0,int>::type type1; typedef boost::mpl::push_back<type1,char>::type type2; return 0; } This fails in MSVC 6.5 and gcc 3.2. The error seems to indicate that push_back does not provide a type named 'type'. If I replace push_back with push_front, eveything works wonderfully. Am I doing any gross error, is the documentation wrong, ideas, clues? Thanx in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

boost::shared_ptr templated constructor?
by Lehrer, Joshua 06 May '03

06 May '03

WRT boost::shared_ptr<>, why not template the explicit constructor that takes a T*? This way, it could select the correct destructor at construction time: struct base { ~base(); }; struct sub : public base { ~sub() }; boost::shared_ptr<base>(new sub); The above code currently only calls ~base(); Templating the explicit single argument constructor would allow the above code to call ~sub(). The constructor now takes only a T*, and therefore populates the pointer to the destructor function with a call to ~T(), which is ~base() in the above example. If, however, the constructor took an X*, the above example would pass a sub*, and it could populate the default destructor function with a pointer to ~X(). Comments? Joshua Lehrer FactSet Research Systems NYSE:FDS

3 2

BGL leaky?
by Martin Okrslar 06 May '03

06 May '03

Dear Boost users, is the BGL leaky? For example the code added below produces memory leaks (as seen from also added valgrind output). When I comment out the line marked by /* THIS LINE DOES IT */, there are no leaks. I am running BGL 1.29 and gcc 3.2. Any ideas for a work-around? cheers Martin #include <iostream> // for std::cout #include <utility> // for std::pair #include <algorithm> // for std::for_each #include <boost/graph/graph_traits.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/dijkstra_shortest_paths.hpp> using namespace boost; int main(int,char*[]) { // create a typedef for the Graph type typedef adjacency_list<vecS, vecS, bidirectionalS> Graph; // Make convenient labels for the vertices enum { A, B, C, D, E, N }; const int num_vertices = N; // writing out the edges in the graph typedef std::pair<int, int> Edge; Edge edge_array[] = { Edge(A,B), Edge(A,D), Edge(C,A), Edge(D,C), Edge(C,E), Edge(B,D), Edge(D,E), }; int num_edges = sizeof(edge_array)/sizeof(edge_array[0]); // declare a graph object Graph* g = new Graph(num_vertices); // add the edges to the graph object for (int i = 0; i < num_edges; ++i) add_edge(edge_array[i].first, edge_array[i].second, *g); /* THIS LINE DOES IT */ delete g; return 0; } okrslar@liebrich:~/molgen/domclust/src/test> valgrind --leak-check=yes --show-reachable=yes ./domclust ==23473== valgrind-1.0.4, a memory error detector for x86 GNU/Linux. ==23473== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==23473== Estimated CPU clock rate is 2412 MHz ==23473== For more details, rerun with: -v ==23473== ==23473== ==23473== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==23473== malloc/free: in use at exit: 384 bytes in 1 blocks. ==23473== malloc/free: 3 allocs, 2 frees, 544 bytes allocated. ==23473== For counts of detected errors, rerun with: -v ==23473== searching for pointers to 1 not-freed blocks. ==23473== checked 6470036 bytes. ==23473== ==23473== definitely lost: 0 bytes in 0 blocks. ==23473== possibly lost: 0 bytes in 0 blocks. ==23473== still reachable: 384 bytes in 1 blocks. ==23473== ==23473== 384 bytes in 1 blocks are still reachable in loss record 1 of 1 ==23473== at 0x4004A3A8: __builtin_new (vg_clientfuncs.c:125) ==23473== by 0x4004A3F6: operator new(unsigned) (vg_clientfuncs.c:138) ==23473== by 0x4035E4F1: ??? (bits/stl_alloc.h:482) ==23473== by 0x4035E40D: ??? (bits/stl_alloc.h:532) ==23473== ==23473== LEAK SUMMARY: ==23473== definitely lost: 0 bytes in 0 blocks. ==23473== possibly lost: 0 bytes in 0 blocks. ==23473== still reachable: 384 bytes in 1 blocks. ==23473== -- ----------------------------------------------------------------------------- Martin Okrslar MPI for Molecular Genetics phone: ++ 49 + 30 / 8413-1166 Computational Molecular Biology Fax: ++ 49 + 30 / 8413-1152 Ihnestrasse 73 email: okrslar(a)molgen.mpg.de D-14195 Berlin URL: http://cmb.molgen.mpg.de -----------------------------------------------------------------------------

2 1

More Mac Compiler Woes - Boost 1.30.0 - Thread and type_traits
by Bobby Thomale 05 May '03

05 May '03

Hey guys, I am having some more problems getting Boost 1.30 to compile on the Mac. I am using CW Pro 8.3, compiling a TARGET_CARBON project. I am having trouble getting the MP implementation of threads to compile. It seems to be having trouble with function pointers where the syntax function<type> is used. I remember at one point it was mentioned that: function<type, type...> was deprecated and we were to use either the more universally supported: functionN<type,type...> or the cleaner: function<void myfuncSig()> instead if our compiler supported it. (Mine doesn't support that last one yet I don't think.) I am guessing that the oldest syntax was removed and no one has bothered to update the Mac carbon thread implementaton to compile again since then? That one seems pretty easy to fix - just update to a supported syntax? (I could do this, update to the functionN<type,type...> syntax since that is what my compiler supports. If someone wants me to make and submit the changes to them for inclusion I'd be happy to, if I knew who to send them to...) Or is there a better/easier workaround? Secondly, the Signals library is not compiling. It's actually not a Signals problem, I think it is a type_traits problem. I am getting a bunch of strange compile errors, in a boost::type_traits file called: is_base_and_derived.hpp It looks like there is a template near the top that is the first thing that fails. There is a define that goes into an alternate implementation for certain broken compilers. Perhaps CodeWarrior needs to be added to the list of compilers that compiles the "broken compiler" version of the stuff in this header? Thanks in advance for your help! -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------

5 6

bug in pthreads implementation of recursive_mutex
by Feldman, Yulik 05 May '03

05 May '03

Hi, It looks that there is a bug in .../boost_1_30_0/libs/thread/src/recursive_mutex.cpp. The bug shows in the pthreads implementation of the recursive_mutex when the mutex is used with the "condition" synchronization primitive. Here is the description of the bug: When the client code calls wait() function on a condition sending as a parameter a lock object associated with a recursive_mutex ("m_Condition.wait(Lock)"), the following functions get called: boost::condition::wait(L& Lock) at condition.hpp:91 boost::condition::do_wait(M& mutex) at condition.hpp:137 boost::detail::thread::lock_ops<boost::recursive_mutex>::unlock(Mutex& m, lock_state& state) at lock.hpp:54 boost::recursive_mutex::do_unlock(cv_state& state) The implementation of the last function on "winthreads" and "mptasks" resets the 'm_count' data member to zero. The "pthreads" implementation at recursive_mutex.cpp:399 doesn't reset the 'm_count' to zero. As a result, when the calling thread enters pthread_cond_wait() and the mutex is unlocked by the pthreads the 'm_count' still remains non-zero. Starting from this point, the things may go bad. Consider, for example, that another thread tries to acquire the mutex. The thread calls: boost::recursive_mutex::scoped_lock Lock(m_Mutex) boost::detail::thread::scoped_lock<boost::recursive_mutex>::scoped_lock<boos t::recursive_mutex>(Mutex& mx, initially_locked = true) at lock.hpp:66 boost::detail::thread::scoped_lock<boost::recursive_mutex>::lock() at lock.hpp:76 boost::detail::thread::lock_ops<boost::recursive_mutex>::lock(Mutex& m) at lock.hpp:34 boost::recursive_mutex::do_lock() at recursive_mutex.cpp:307 The last function locks the mutex again, and, if BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE is defined, increments the counter to 2. Now, since the count is more than 1, the function unlocks the mutex. As a result, the mutex remains unlocked, after the lock function is called. The same problem exists in recursive_try_mutex and recursive_timed_mutex. I've tried to fix the code as follows, which seemed to help in my particular case: ---------------------------------------------------------------------------- ------------------------------------ *** recursive_mutex.cpp.orig Sun Feb 23 19:38:11 2003 --- recursive_mutex.cpp Sat May 3 17:32:44 2003 *************** *** 412,417 **** --- 412,418 ---- state.pmutex = &m_mutex; state.count = m_count; + m_count = 0; } recursive_try_mutex::recursive_try_mutex() *************** *** 608,613 **** --- 609,615 ---- state.pmutex = &m_mutex; state.count = m_count; + m_count = 0; } recursive_timed_mutex::recursive_timed_mutex() *************** *** 787,792 **** --- 789,795 ---- state.pmutex = &m_mutex; state.count = m_count; + m_count = 0; } #elif defined(BOOST_HAS_MPTASKS) ---------------------------------------------------------------------------- ------------------------------------ Any comments? Is this indeed a bug? Is the fix correct? Thanks, Yulik. [Non-text portions of this message have been removed]

3 2

uBlas - matrix comparison A == B -> how-to guide ...
by geert_ceuppens 05 May '03

05 May '03

Sharing my effort in working with ublas ... Forgive me if this is described already somewhere - I could not find it immediately in the doc so I looked around in the code ; ) Matrix comparison is implemented using the equals() method defined in matrix_assign.hpp: bool equals (const matrix_expression<E1> &e1, const matrix_expression<E2> &e2) Code snippet: ublas::matrix<double> A(5,5), B(5,5); // Initialise A somehow init_matrix(A); B = A; // This does not compile ... bool equal = ( A == B ); // But this does (and it works ...) bool equal = ublas::equals ( A, B );

1 0

RE: [Boost-Users] How To Build Boost 1.30 With Dev-CPP?
by bjorn.karlsson＠readsoft.com 04 May '03

04 May '03

> From: firingme [mailto:yg-boost-users@m.gmane.org] > E:\LY\boost_1_30_0>bjam sTOOS=mingw This should read sTOOLS, not sTOOS. Bjorn

5 5

RE: [Boost-Users] Code Fail
by Jim.Hyslop 02 May '03

02 May '03

Hossein Haeri [mailto:powerprogman@yahoo.com] wrote: > There is a tiny cpp file attached to this message > that raises the following exception while running: No, there isn't ;-) The email list strips out attachments. If it truly is tiny, then paste it inline. If it's not-so-tiny, then you can upload it to the files area: http://groups.yahoo.com/group/Boost-Users/files/ -- Jim

1 0

RE: [Boost-Users] Re: Is there a "known issues" page anywhere?
by Jim.Hyslop 02 May '03

02 May '03

Alisdair Meredith [mailto:yg-boost-users@gmane.org] wrote: > "Jim.Hyslop" wrote: > > > There is a "Known Issues" section on the wiki (see the link in the > > auto-appended .sig) which is intended to document these > common "gotchas". I > > haven't looked at it for a while, so I don't know how > up-to-date it is. > > I tried looking there first, and after your message went back for a > second look. > Perhaps I am being dense, but I really can't find it. > Closest match is > the 'build issues' page, which I think is for a different thing. > 'Search' the wiki did not help either. That's the page I meant - CommonBuildProblems: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?CommonBuildPr oblems Sorry about the confusion. Your problem with the lexical_cast is the precise reason I created the page. > Could you post a link to the precise page you were thinking > about? And > I think a more prominent link on the front page may be useful too. There's one under the "Quick Links" section, but as you say it's not very prominent. Remember, the point of a wiki is that *anyone* can change the information. If you think it deserves a more prominent position, then you are free to give it one :=) -- Jim

1 0

PP library...
by Eric Robert 02 May '03

02 May '03

Hi, I think the preprocessor library could help me here but I'm having problems understanding it. Maybe someone will be so kind to explain it to me a bit. Here is what I want to produce: void foo(char); void foo(int); void foo(unsigned int); .... You got the idea. Something that repeats a list of things i.e. here, types. How can I do that? Thanks! Eric [Non-text portions of this message have been removed]

3 3

Code Fail
by Hossein Haeri 02 May '03

02 May '03

Dear all, There is a tiny cpp file attached to this message that raises the following exception while running: "Project ConstStatProject.exe raised exception class EAccessViolation with message 'Access violation at adress ...'. Process stopped. Use Step or Run to continue." and stops at the following line of the share_ptr library: if(use_count_ == 0 && weak_count_ != 0) boost::throw_exception(boost::bad_weak_ptr()); Can anybody help me? BTW, I'm using BCB6. Thanks, --Hossein __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com [Non-text portions of this message have been removed]

1 0

[BGL] Online Graph Algorithms (fwd)
by David Pearce 02 May '03

02 May '03

Hello, I am interested in how boosters think online graph algorithms should be written. I have looked at the connected_components algorithm and feel that it breaks some of the ideas behind generic programming. For example, consider the following: > typedef adjacency_list <vecS, vecS, undirectedS> Graph; > Graph G(6); > add_edge(0, 1, G); > add_edge(1, 4, G); > > // create the disjoint-sets structure, which requires > // rank and parent vertex properties > ... > initialize_incremental_components(G, ds); > incremental_components(G, ds); > > generic_algorithm_which_adds_edges(G); At this point, the connected_components data structures may be out-of-sync. Now, I suppose that we could write a wrapper class which looked like a "Graph" and provides its own add_edge to update "ds" correctly. However, this seems overly cumbersome. It strikes me that a better way of doing this would be to use an abstract base class, like so: > template<class T, ...> > class connected_components : public T { > ... > }; > > template<class T> > pair<T::edge_descriptor, bool> > add_edge(connected_components<T>::vertex_descriptor t, ...) { > // do stuff > return add_edge(static_cast<T::vertex_descriptor>(t), ...); > } Thus, we supply "Graph" as the base class and can then safely pass it to "generic_algorithm_which...". So, does anyone know of any reasons not to do this? Cheers, David J. Pearce

1 0