- Boost - lists.preview.boost.org

RE: [boost] Re: "memory access violation" in boost::serialization
by Dirk Griffioen 13 Jul '04

13 Jul '04

Thanks Jeff, Your solution works - with a little twist: I took the solution from #20 (thanks Robert!) and now it loooks like: if(NULL != t.pi_) t.pi_->add_ref_copy(); I also outcommented line 125. & now my app works fine! We will, however, upgrade to #20 as soon as possible. Regarding the little discussion: it might very well be the case that uses find the library very usefull, without too many a problem. We certainly do, for instance on windows 2k (vc71) and HP True64 (probably gcc but I'm not sure). We have a lot of platforms here (HP, AIX, SUN, VMS, AS400 and Mainframe - with different versions of native compilers and/or gcc) and it is likely we will port to those platforms. If there's an interest, it might be possible to gather some figures. Cheers, Dirk -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Flinn Sent: maandag 12 juli 2004 17:07 To: boost(a)lists.boost.org Subject: [boost] Re: "memory access violation" in boost::serialization "Dirk Griffioen" <d.griffioen(a)HumanInference.com> wrote in message news:2505062E579A9B45888B70D9BCFB3C073BA8BD@ex03.hidomain... > Hi, > > I encountered the following little problem: > > I would like to use the following datastructures with boost::serialize: > > struct Match {}; > typedef std::string Key; > typedef tst< Match, Key > TernarySearchTree; //this one has a shared_ptr > > typedef std::vector< TernarySearchTree > Trees; > typedef std::map< std::string, Trees > Symbols; > > I have defined some serialize overloads so saving goes fine, but when > loading I get a "memory acces violation" inside the following code: > > { > boost::archive::text_iarchive ia(ifs); > ia >> symbols_; > } > > More specific, inside <boost/serializiton/shared_count.hpp> > > void add_ref_copy() > { > #if defined(BOOST_HAS_THREADS) > mutex_type::scoped_lock lock(mtx_); > #endif > ++use_count_; > } > > Which constructs a scoped_lock, and there, the "explicit > scoped_lock(lightweight_mutex & m): m_(m)" seems to go wrong. Actually you'll find that the this pointer is either NULL or invalid. > > What could be the reason? The more since all worked fine (saving and > loading) when I used a simple vector of tst's. The following changes to .../boost/serialization/shared_ptr.hpp should do it: change line 74: if(t) t->add_ref_copy(); and comment out line 125: // shared_ptr_access::weak_count(*t) = 0; IIRC, line 125 is the primary culprit. ----------------- Jeff Flinn Applied Dynamics, International _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Pretty Good Initialization Library
by Andrei Alexandrescu (See Website for Email) 13 Jul '04

13 Jul '04

Just sent the message below to clc++m. Any comments are welcome. There's a library that I understand is being proposed for Boost: http://www.codeproject.com/vcpp/stl/PGIL.asp It does useful things, but it runs straight against the commonly given advice (with which I happen to agree) that one should not override operator, unless using expression templates that ensure left-to-right evaluation. So now, in the referenced article, the author makes the comment: " Overloading operator comma is sometimes viewed as a bad practice [3]. However, it has been done with success in eg. the Generative Matrix Computation Library and Blitz to initialize matrices (see [4]) and [5]). The Initialization Library overloads the comma operator in a safe manner by letting set_cont and set_map return an object that is responsible for the initialization. Therefore it takes explicit action from the programmer to begin using the overloaded operator,(). " I think the mentioned libraries do employ expression templates, while the initialization library does not. So I am unsatisfied. Anyone here can soothe my concerns? Is overloading the comma operator considered harmless after all? Andrei

11 34

"bin" directories clean-up [Was: Regression testing goes horribly wrong! (+ patch)]
by Aleksey Gurtovoy 13 Jul '04

13 Jul '04

Guillaume Melquiond writes: > Le lun 12/07/2004 à 04:22, Aleksey Gurtovoy a écrit : > > [...] > > > > Maybe you did patch some Jamfiles or bjam? > > > > "boost\tools\build\v1\testing.jam" > > Great! > > > I don't know if it is actually necessary (or if it is even possible), > but maybe a similar patch should be applied to bjam v2? Most likely, but that's something we can worry about after the release. > I have another concern. Maybe I'm overly pessimistic, but I think > regression testers should restart their testing from scratch (rm -r > boost/bin, or whatever it is called) now that the format has changed, > shouldn't they? If somebody is still experiencing the problems we were fighting, yes. Looking at the reports, it seems that SunOS and Darwin platforms might need it. BTW, it would be nice if these reports' comments listed a contact point. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Generalizing the shared_ptr
by Maciej Sobczak 13 Jul '04

13 Jul '04

Hi, (not sure if it was discussed before) I've found Boost smart pointers inflexible in the sense that they operate only on pointers. It would be a good idea to generalize their interface to handle just about anything that requires special care when destroying. HANDLE (on Windows), FILE*, file descriptors (on Unix), third-party API handles, etc. come to mind. I wrote a very simple class (see attachments), scoped_handle, which encapsulates the resource (whatever it is) and its disposing (whatever that means). The techniques used are similar to those used in implementation of boost::shared_ptr. The example file shows how the class can be used to guard resources allocated by operator new, fopen, open, etc. Is it possible to achieve the same results with the existing Boost libraries? If not, is there any interest in developing this kind of class? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ // // Copyright (C) 2004 Maciej Sobczak // http://www.msobczak.com/ // // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. // This software is provided "as is" without express or implied // warranty, and with no claim as to its suitability for any purpose. // #ifndef SCOPED_HANDLER_H_INCLUDED #define SCOPED_HANDLER_H_INCLUDED template <typename Resource> class disposer_base { public: virtual ~disposer_base() {} virtual void dispose(Resource) = 0; }; template <typename Resource, typename Deleter> class disposer_impl : public disposer_base<Resource> { public: disposer_impl(Deleter d) : d_(d) {} void dispose(Resource r) { d_(r); } private: Deleter d_; }; template <typename Resource> void simpleDeleter(Resource r) { delete r; } template <typename Resource> void arrayDeleter(Resource r) { delete [] r; } // requirements: // Resource and Deleter are copy-constructible and do not throw while copying // For Resource r and Deleter d, d(r) is a valid expression that doesn't throw template <typename Resource> class scoped_handle { public: scoped_handle(Resource r) : r_(r) { initDeleter(simpleDeleter<Resource>); } template <typename Deleter> scoped_handle(Resource r, Deleter d) : r_(r) { initDeleter(d); } ~scoped_handle() { disp_->dispose(r_); delete disp_; } Resource get() const { return r_; } private: scoped_handle(const scoped_handle &); scoped_handle & operator=(const scoped_handle &); template <typename Deleter> void initDeleter(Deleter d) { try { disp_ = new disposer_impl<Resource, Deleter>(d); } catch (...) { d(r_); throw; } } disposer_base<Resource> *disp_; Resource r_; }; #endif // SCOPED_HANDLER_H_INCLUDED #include "scoped_handle.h" #include <iostream> #include <functional> // this is for Unix only #include <fcntl.h> #include <unistd.h> using namespace std; class A { public: A() { cout << "A()\n"; } ~A() { cout << "~A()\n"; } }; void specialDeleter(A *p) { cout << "special deleter: "; delete p; } void anotherSpecialDeleter(A *p, int i) { cout << "another special deleter (" << i << "): "; delete p; } int main() { { scoped_handle<A*> h1(new A); scoped_handle<A*> h2(new A, specialDeleter); scoped_handle<A*> h3(new A, bind2nd(ptr_fun(anotherSpecialDeleter), 7)); // resources are released in the reverse order } { scoped_handle<FILE*> h4(fopen("test.txt", "w"), fclose); // ... } { // this is for Unix only scoped_handle<int> h5(open("test.txt", O_RDONLY), close); // ... } // etc. }

2 3

New version of MPL?
by Joaquín Mª López Muñoz 13 Jul '04

13 Jul '04

According to 1.32 release plans, a new version of MPL would have to be checked in main CVS by Sunday; if I'm not wrong, this hasn't happened yet. * Any news regarding the new MPL? * Is still July 16 a realistic date for branching? Unless the new MPL checks in real smooth, I'm afraid 4 days is probably too little time to tidy everything up. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Boost.Random patch for gcc-3.4.1
by Synge Todo 13 Jul '04

13 Jul '04

Dear Boosters, I'm sending a small patch for Boost.Random to compile by using gcc-3.4.1 (on Linux Fedora Core 2). Could somebody apply this patch? Thank you in advance. Best regards, Synge Todo diff -crN boost-20040713.orig/boost/random/lagged_fibonacci.hpp boost-20040713/boost/random/lagged_fibonacci.hpp *** boost-20040713.orig/boost/random/lagged_fibonacci.hpp Fri Jul 2 10:21:32 2004 --- boost-20040713/boost/random/lagged_fibonacci.hpp Tue Jul 13 14:10:44 2004 *************** *** 23,28 **** --- 23,29 ---- #include <iostream> #include <algorithm> // std::max + #include <cmath> #include <iterator> #include <boost/config.hpp> #include <boost/limits.hpp> diff -crN boost-20040713.orig/boost/random/subtract_with_carry.hpp boost-20040713/boost/random/subtract_with_carry.hpp *** boost-20040713.orig/boost/random/subtract_with_carry.hpp Fri Feb 27 03:26:54 2004 --- boost-20040713/boost/random/subtract_with_carry.hpp Tue Jul 13 14:10:56 2004 *************** *** 23,28 **** --- 23,29 ---- #include <iostream> #include <algorithm> // std::equal + #include <cmath> #include <stdexcept> #include <boost/config.hpp> #include <boost/limits.hpp>

1 0

Lambda and VC71 ICE
by Richard Crossley 13 Jul '04

13 Jul '04

With the current CVS I'm getting an ICE with VC71. Console project, single .cpp file containing the single line: #include <boost/lambda/bind.hpp> Compiling... lambda_fail.cpp C:\boost\boost\lambda\detail\lambda_functors.hpp(172) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Tried various permutations of complier options but the ICE is consistent. Regards, Richard.

2 1

Re:[boost] "memory access violation" in boost::serialization
by Robert Ramey 12 Jul '04

12 Jul '04

I presume you are using serialization draft # 18 upload last april. Since then helpful users have found a couple of bugs which I have subsequently fixed. There is a more recent version that I have tested with boost 1.31 at www.rrsd.com. It is labeled serialization #20. I am currently struggling - so far with only limited success - in getting the most recent version of the serialization library checked in to the main boost CVS. This as been too slow to get it done but too fast to give up on. Regarding your particular problem, I believe that this came up under the the condition where a n object is saved through a pointer to its base class and it was not registered or exported. This has been addressed in the current library by throwing an exception. Of course this helps characterize the problem - but it doesn't really fix the cause. This latter one has to do himself. BTW, there have been a couple of other small bug fixes related to some collections (hmm - map was among them!)- this might or might not address your symptoms. Another bug in the serialization of shared_ptr was uncovered which was causing a memory leak. I hope all this helps. Thanks for the feedback. As an aside - I notice that I'm getting about 300 downloads/month of the serialization package from my web site. I have no information about downloads from the Yahoo/Boost files area - (which I would be curious to know). I get very little feedback - I'm wondering if lots of downloaders take a look and decide it's too complex to actually use. Robert Ramey >Hi, >I encountered the following little problem: >I would like to use the following datastructures with boost::serialize: >struct Match {}; >typedef std::string Key; >typedef tst< Match, Key > TernarySearchTree; //this one has a shared_ptr >typedef std::vector< TernarySearchTree > Trees; >typedef std::map< std::string, Trees > Symbols; >I have defined some serialize overloads so saving goes fine, but when >loading I get a "memory acces violation" inside the following code: >{ > boost::archive::text_iarchive ia(ifs); > ia >> symbols_; >} >More specific, inside <boost/serializiton/shared_count.hpp> > void add_ref_copy() > { >#if defined(BOOST_HAS_THREADS) > mutex_type::scoped_lock lock(mtx_); >#endif > ++use_count_; > } >Which constructs a scoped_lock, and there, the "explicit >scoped_lock(lightweight_mutex & m): m_(m)" seems to go wrong. >What could be the reason? The more since all worked fine (saving and >loading) when I used a simple vector of tst's. >Is it not possible to use a map of string/vector (the error seems to >suggest the library failing when copying vector to map - eg ++use_count >of the shared_ptr inside the TST).

3 2

RE: [boost] Generalizing the shared_ptr
by Max Khesin 12 Jul '04

12 Jul '04

As of version 3.1 boost shared_ptr has a constructor that takes a user-defined deleter: template<class Y, class D> shared_ptr(Y * p, D d): px(p), pn(p, d) { detail::sp_enable_shared_from_this(p, p, pn); } Maybe I missed something, but what is your library adding to this? m -----Original Message----- From: Maciej Sobczak [mailto:prog@msobczak.com] Sent: Wednesday, July 07, 2004 4:18 PM To: boost(a)lists.boost.org Subject: [boost] Generalizing the shared_ptr << File: scoped_handle.h >> << File: test.cc >> << File: ATT57508.txt >> Hi, (not sure if it was discussed before) I've found Boost smart pointers inflexible in the sense that they operate only on pointers. It would be a good idea to generalize their interface to handle just about anything that requires special care when destroying. HANDLE (on Windows), FILE*, file descriptors (on Unix), third-party API handles, etc. come to mind. I wrote a very simple class (see attachments), scoped_handle, which encapsulates the resource (whatever it is) and its disposing (whatever that means). The techniques used are similar to those used in implementation of boost::shared_ptr. The example file shows how the class can be used to guard resources allocated by operator new, fopen, open, etc. Is it possible to achieve the same results with the existing Boost libraries? If not, is there any interest in developing this kind of class? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

5 4

[optional] outdated tests?
by Rene Rivera 12 Jul '04

12 Jul '04

Boost.Optional optional_test and optional_test_ref both have the following error: Cannot open include file: 'boost/detail/none.hpp': No such file or directory. But only on the Win32 tests, and not on the Linux test. Not sure what the discrepancy is about but the file is definitely not there in CVS. It got moved from boost/detail/none.hpp to boost/none.hpp. So if no one minds I'll fix it. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 3

Boost Socket
by Dan 12 Jul '04

12 Jul '04

Hugo Duncan has been laboring over what will hopefully be the Boost socket library. I need to do quite a bit of network programming so I would like to get in contact with Hugo. Hopefully Hugo reads this, but if not, does anybody know how to contact him? I've tried emailing him at his sourceforge address but so far haven't received a response. I'd like to find out what the status of his library is and hopefully help him complete and test the relevant parts of it. -Dan "The only impossible task is the task you never start"

2 1

Re: Boost Digest, Vol 779, Issue 4
by François Dumont 12 Jul '04

12 Jul '04

Thanks for your advise about avoiding the call_traits library. I finaly based my code on the type_traits library even if the param_type from call_traits is quite a usefull type. If call_traits was deprecated putting a param_type in type_traits sounds to me like a good idear. About the doc I also had the feeling of an incomplete one for type_traits for 2 reasons. add_const<add_reference> do not lead to the same type as add_reference<add_const>, even if I agree with this behavior, a little note about it in the doc would be great. Second is about the compiler support of the type_traits feature. Isn't there yet any compiler able to give info about the compiled types? But of course it might appear as a commercial information so it is only a suggestion. Just for you to know my major insterest in boost is not in its type_traits library but in the move semantic lib. How is it going? For the coming STLport version I have added a very simple move constructor framework. It is not documented as I don't think that STLport is the right place for this kind of library. As soon as the next STLport version is released I will have a closer look on the boost move semantic lib. Francois Dumont > > Date: Mon, 05 Jul 2004 16:55:50 -0400 > From: David Abrahams <dave(a)boost-consulting.com> > Subject: [boost] Re: Fw: STLport & boost > To: boost(a)lists.boost.org > Message-ID: <uzn6erx61.fsf(a)boost-consulting.com> > Content-Type: text/plain; charset=iso-8859-1 > > François Dumont <francois.cppdevs(a)free.fr> writes: > > > Hello > > > > I am currently actively contributing to STLport. One of my > > contribution is to make boost and STLport closer. I think STLport can > > gain a lot in using some of the boost libraries and then boost will be > > able to count on a robust std lib. > > This sounds really cool, BTW. > > > For the moment I only use 2 libraries from boost, type_traits and > > call_traits. > > Take care with call_traits. The documentation isn't very clear about > how it behaves in all circumstances (especially on broken compilers). > I would be inclined to build my own individual metafunctions (rather > than traits "blobs") for doing the kinds of thigs that call_traits > tries to address. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com >

2 1

Question about Boost.Random
by Anders Edin 12 Jul '04

12 Jul '04

// The following program illustrates a problem in Boost.Random. // Is this the desired behavior? // If so, what is the reason for this? // I use Boost version 1.31 and GCC version 3.3.3 on Suse 9.1 #include <vector> #include <algorithm> #include <boost/random.hpp> // Definition of the random number generator typedef boost::mt19937 engine_t; typedef boost::uniform_int<int> distribution_t; typedef boost::variate_generator<engine_t, distribution_t> rng_t; int main() { const unsigned int N = 13, A = 0, B = 1000; std::vector<int> run1(N), run2(N), run3(N); // Generate some random integers { engine_t engine; distribution_t distribution(A,B); rng_t rng(engine, distribution); std::generate(run1.begin(), run1.end(), rng); } // Verify that I get the same sequence if I start again { engine_t engine; distribution_t distribution(A,B); rng_t rng(engine, distribution); std::generate(run2.begin(), run2.end(), rng); } // It appears that the generator restarts for each generate, since // the generate algorithm creates a copy of the functor so that // its state is lost { engine_t engine; distribution_t distribution(A,B); rng_t rng(engine, distribution); std::generate(run3.begin(), run3.begin()+N/2, rng); std::generate(run3.begin()+N/2, run3.end(), rng); } // For me it would seem more natural if the engine class would be a // singleton, so that there can be only one object of any particular // random generator engine type. // Our purpose for using random numbers is to simulate physical processes. // I can't think of a case when there would be a need for several random // engines, even if there can of course be many different random // distributions in an application. // Having the same random number sequence in different parts of a simulation // can probably create very strange behaviour, since the numbers from the // different engines of the same type will be perfectly correlated. // Perhaps other applications have use of several random engines? for(unsigned i=0; i<N; ++i) { if(i==N/2) std::cout<<"Halfway there!"<<std::endl; std::cout <<run1[i] <<" == "<<run2[i] <<" == "<<run3[i] <<std::endl; } return 0; } // Anders Edin // Sidec Technologies AB

2 3

"memory access violation" in boost::serialization
by Dirk Griffioen 12 Jul '04

12 Jul '04

Hi, I encountered the following little problem: I would like to use the following datastructures with boost::serialize: struct Match {}; typedef std::string Key; typedef tst< Match, Key > TernarySearchTree; //this one has a shared_ptr typedef std::vector< TernarySearchTree > Trees; typedef std::map< std::string, Trees > Symbols; I have defined some serialize overloads so saving goes fine, but when loading I get a "memory acces violation" inside the following code: { boost::archive::text_iarchive ia(ifs); ia >> symbols_; } More specific, inside <boost/serializiton/shared_count.hpp> void add_ref_copy() { #if defined(BOOST_HAS_THREADS) mutex_type::scoped_lock lock(mtx_); #endif ++use_count_; } Which constructs a scoped_lock, and there, the "explicit scoped_lock(lightweight_mutex & m): m_(m)" seems to go wrong. What could be the reason? The more since all worked fine (saving and loading) when I used a simple vector of tst's. Is it not possible to use a map of string/vector (the error seems to suggest the library failing when copying vector to map - eg ++use_count of the shared_ptr inside the TST). Thanks in advance, Dirk

2 1

[Boost-bugs] [ boost-Bugs-989487 ] wrong usage of ios_base::narrow
by SourceForge.net 12 Jul '04

12 Jul '04

Bugs item #989487, was opened at 2004-07-12 22:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=989487&group_i… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vyacheslav E. Andrejev (vandrejev) Assigned to: Jeff Garland (az_sw_dude) Summary: wrong usage of ios_base::narrow Initial Comment: /cvsroot/boost/boost/boost/date_time/date_parsing.hpp revision 1.18, lines 207, 214 std::stringstream has char_type typedef evidently equal to char, not wchar_t, so in std::stringstream::narrow function the first argument has type char and in the call ss << ss.narrow(*beg++, 'X'); *beg will be converted from wchar_t to char before call to narrow will be made. I suggest the following patch: diff -c -r1.18 date_parsing.hpp *************** *** 207,214 **** wchar_t) { std::stringstream ss(""); while(beg != end) { ! ss << ss.narrow(*beg++, 'X'); // 'X' will cause exception to be thrown } return parse_date<date_type>(ss.str()); } --- 207,215 ---- wchar_t) { std::stringstream ss(""); + std::locale loc; while(beg != end) { ! ss << std::use_facet<std::ctype<wchar_t> > (loc).narrow(*beg++, 'X'); } return parse_date<date_type>(ss.str()); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=989487&group_i… ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Problem about build regex under win32 using stlpot5.0
by huangliang 12 Jul '04

12 Jul '04

Recently I begin to use stlport in my programs, and I want to build boost regex under win32 using vc6 and stlport 5.0. But when I build them,the following errors occurs: C:\lib\boost-1.30.2\libs\regex\build>set MSVCDIR= D:\Program Files\Microsoft Visual Studio\VC98\Bin C:\lib\boost-1.30.2\libs\regex\build>set STLPORT_PATH=E:/HuangLiang/c++stl/STLport-5.0-1031 C:\lib\boost-1.30.2\libs\regex\build>nmake -fvc6-stlport.mak cl /nologo /MT /W3 /GX /O2 /GB /GF /Gy /IE:/HuangLiang/c++stl/STLport-5.0-1031\stlport /I..\..\..\ /D_MT /DWIN32 /DNDEBUG /D_MBCS /D_LIB /YX /FD /c -Fpvc6-stlport/boost_regex_vc6-stlport_mss/boost_regex_vc6-stlport_mss.pch -Fo./vc6-stlport/boost_regex_vc6-stlport_mss/ -Fdvc6-stlport/boost_regex_vc6-stlport_mss.pdb ../src/cpp_regex_traits.cpp cpp_regex_traits.cpp ../src/cpp_regex_traits.cpp(662) : error C2660: 'isspace' : function does not take 2 parameters ../src/cpp_regex_traits.cpp(662) : fatal error C1903: unable to recover from previous error(s); stopping compilation After I searched msdn, I found that isspace have been defined at 2 places: isspace template<class E> bool isspace(E c, const locale& loc) const; The template function returns use_facet< ctype<E> >(loc). is(ctype<E>:: space, c). and in ctype.h. I remember when I compile regex using vc6 without stlport, no same errors occured. I need some help about what has happened with me. Thank you !

2 1

VC 7.1: unable to bind specialized member function template
by Stefan Slapeta 12 Jul '04

12 Jul '04

Hi all, this code sample produces a compiler error on VC 7.1. It seems that boost::bind isn't able to get the right type for the specialization of the member function template [&Test::g<Type1, Type2>]. Is there a good workaround? (The only one I could find so far is to 'hide' the function template as normal member function in a class template.) Intel 8.0 compiles ok! #include <boost/bind.hpp> #include <boost/function.hpp> class Test { public: template <typename Type1, typename Type2> void f(Type1 one, Type2 two) { boost::function<void (Type1, Type2)> bf = boost::bind(&Test::g<Type1, Type2>, this, one, two); } template <typename Type1, typename Type2> void g(Type1, Type2) { } }; int main() { Test t; t.f(0, 0); }

2 3

[Boost-bugs] [ boost-Bugs-989168 ] intrusive_ptr may cause dungling ptr access
by SourceForge.net 12 Jul '04

12 Jul '04

Bugs item #989168, was opened at 2004-07-11 20:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=989168&group_i… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: intrusive_ptr may cause dungling ptr access Initial Comment: I think intrusive_ptr may cause dungling ptr access in multithreaded environment. Currently, it's constructor is: intrusive_ptr(T * p, bool add_ref = true) : p_(p) /* the object may be deleted by other thread because this thread does not increment reference counter yet. */ { if(p_ != 0 && add_ref) intrusive_ptr_add_ref(p_); /* this may occur dungling ptr operation. */ } We can avoid this problem by "addref-before-use" policy. intrusive_ptr(T * p, bool add_ref = true) { if(p != 0 && add_ref) intrusive_ptr_add_ref(p_); /* other thread never delete the object */ p_ = p; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=989168&group_i… ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Yet more math functions - a draft TR2 proposal
by Paul A Bristow 12 Jul '04

12 Jul '04

I posted a note previous with modest reponse. In the hope that a better link will provoke some more reaction, I am reposting. As promised recently, I am presenting a draft of proposals for math functions which are needed for even most elementary statistics. I have been encouraged to submit this to both the C and C++ Standard Library groups at the same time. (They seem to speaking more than in the past). These are additions to the list drawn up by Walter Brown accepted into TR-1. The style and format follows his closely even though there were some opposition to them from the C++ community. However I think we have to accept that C and C++ compatibility are valued more than C++ 'ideality', and not try to re-open this area of dissent. The draft has been uploaded to the files area in a new folder Math Functions as "More Mathematical Functions.pdf" 220 kb. It is accessible at: http://tinyurl.com/357a6 be grateful if some CVS whizz would copy it to the sandbox as I know that many are unable to access the files section. It would be useful to have comments on 1 Typographical mistakes. 2 Mathematical mistakes (prepared by someone with seriously rusty math!). 3 The choice of functions espcially if there are any your feel strongly are missing, or are not needed (say why). 4 The choice of names. Clarity is preferred to curtness. 5 The choice of names for derivatives like the inverse and complement. I have added suffixes _inc and _c (or _com?). ( for C there will be suffixes f and l for the float and long double versions). Thanks. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

3 2

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 11 Jul '04

11 Jul '04

What a wonderfully clean suggestion of having just one lock and (hopefully) just one mutex. IMHO having just one mutex class is even more important than having one lock as mutex represents something lockable that seems to always be the same. That is, I create a mutex and sometimes want to apply a blocking lock on it and sometimes I just want to try a lock. The functionality that implements various ways of locking is in locks. Although I can see the technical merits of having just one lock constructor, I still feel that having two explicit instead would be less ambiguous, friendlier towards the user and cleaner. Additionally, it'd keep the door open for possible optimization. Additionally, I'd expect the scoped_lock l(m, true) to be used much more often than scoped_lock l(m, false) Consequently, IMHO the first should get the preferential treatment. That is, to have an explicit and more efficient representation: scoped_lock::scoped_lock(Mutex&) Best, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Sunday, 11 July 2004 10:47 PM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Boost.Threads: Do we need all those mutexes? Michael Glassford wrote: > Peter Dimov wrote: >> After giving it some thought: >> >> - one lock class: tie; > > This seems both popular and reasonable. I presume it would be > templated on the mutex type? Seems entirely reasonable. Perhaps it's time to move to formal wording. template<class M> class scoped_lock { public: explicit scoped_lock( M & m, bool l = true ); // effects: if( l ) m.lock(); // post: locked() == l && mutex() == &m; ~scoped_lock(); // effects: if( locked() ) mutex()->unlock(); void lock(); // throws: lock_aready_locked if locked(); // effects: mutex()->lock(); // post: locked(); bool try_lock(); // throws: lock_aready_locked if locked(); // returns: mutex()->try_lock(); // post: locked() == (return value); bool timed_lock( xtime xt ); // throws: lock_aready_locked if locked(); // returns: mutex()->timed_lock( xt ); // post: locked() == (return value); void unlock(); // throws: lock_not_locked when !locked(); // effects: mutex()->unlock(); // post: !locked(); bool locked() const; Mutex * mutex() const; // returns: the associated mutex; operator unspecified-bool-type() const; // returns: locked(). }; I've added the mutex() accessor to support Andrei's lock idiom: void f() { scoped_lock lock( my_mutex ); f( lock ); } void f( scoped_lock & lock ) { // check for lock validity assert( lock.locked() && lock.mutex() == &my_mutex ); // proceed with operation } Now that we got rid of the excess locks, how about doing the same with the mutexes? class mutex // DefaultConstructible { private: void lock(); // pre: *this is not locked by the current thread // effects: blocks until *this is unlocked // post: *this is locked by the current thread bool try_lock(); // returns: true iff *this was unlocked // post: if *this was unlocked, *this is now locked by the current thread bool timed_lock( xtime xt ); // returns: true if *this is now locked by the current thread // effects: if *this is unlocked, returns immediately, otherwise blocks // until either *this is unlocked or xt has been reached // post: if *this was or became unlocked, *this is now locked by the // current thread void unlock(); // pre: *this is locked by the current thread // post: *this is unlocked }; The main potential issue here is mutex::timed_lock; try_lock doesn't seem controversial. It is true that Windows 95 does not have TryEnterCriticalSection, but an implementation can use Alexander Terekhov's alternative: http://lists.boost.org/MailArchives/boost/msg64648.php The mutex::timed_lock situation is a bit more complicated. POSIX labels pthread_mutex_timedlock as part of the Timeouts option, and I don't know whether this is because many implementations deliberatley do not provide timed locks, or because this is a relatively new addition to pthreads. Does someone know? My not-so-informed opinion at the moment is that we should provide timed_lock. I see that the current Boost.Threads implementation uses a mutex and a condition variable to implement a timed_lock-capable mutex, so we have a proof of concept that it can always be done, however there may be efficiency concerns. My line of thought is that since a mutex (usually) has a fast path user space portion and a slow path kernel space portion, with the timed_lock baggage not affecting the fast path, it seems reasonable to always require timed_lock (remember we're in "next standard mode" now, thinking severals years ahead). Thoughts? Some more random remarks regarding the state of Boost.Threads. Several files still seem to have incorrect line endings. This usually happens when checking in Windows line endings with a Unix CVS client. Please don't do that. I was somewhat surprised by the mutex/cv implementation. I expected a thin wrapper over pthreads, but this is not the case. At first sight it seems that the complexity is caused by the fact that boost::condition supports recursive mutexes that are locked more than once, whereas POSIX does not. I do not recall any discussions about this issue, and I'm not sure why this decision was made. It seems wrong (and the implementation seems buggy), but as usual, I may be missing something. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [optional] outdated tests?
by JOAQUIN LOPEZ MU?Z 11 Jul '04

11 Jul '04

----- Mensaje original ----- De: Rene Rivera <grafik.list(a)redshift-software.com> Fecha: Domingo, Julio 11, 2004 6:13 pm Asunto: [boost] [optional] outdated tests? > Boost.Optional optional_test and optional_test_ref both have the > following error: Cannot open include file: > 'boost/detail/none.hpp': No > such file or directory. > > But only on the Win32 tests, and not on the Linux test. Not sure > what > the discrepancy is about but the file is definitely not there in > CVS. Linux test also fail, but, as discussed in a previous thread, the reports pages are not getting updated due to a XML-related problem. I think Aleksey fixed that, so hopefully the pages will update again soon. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Fw: STLport & boost
by François Dumont 11 Jul '04

11 Jul '04

Hello I am currently actively contributing to STLport. One of my contribution is to make boost and STLport closer. I think STLport can gain a lot in using some of the boost libraries and then boost will be able to count on a robust std lib. For the moment I only use 2 libraries from boost, type_traits and call_traits. I have some issue when I include the boost headers from STLport. I was counting on the BOOST_STD_CONFIG macro to limit the damage but for some platforms this feature is just useless. Under Win32 there is a workaround implemented for MSVC compilers (win32.hpp:60) on the min and max template functions. This workaround require the inclusion of the algorithm standard header which make the STLport lib build process failed. According the comment this workaround has not really been validated so my questions are: - is it require for all MSVC++ versions? Doesn't VC.Net 2003 or even 2002 managed the described cases correctly? - Couldn't this workaround be implemented for the native library only and not when using STLport? STLport looks to me as the right place to handle this case. Bests Francois Dumont

11 24

Linux regressions
by John Maddock 11 Jul '04

11 Jul '04

There appear to be a few regressions in the Linux test results: 1) Several libraries are listed as failing with intel-linux-8 including config_test, regex, and python. However these do pass when tested on my own machine with the latest Intel binaries. Could this be a setup issue? For example if the compiler has recently been patched then you may need to clear out past builds before the tests will start passing again. 2) Test exec monitor is failing with gcc-2.96+STLPort which is causing quite a few other failures. 3) the test results look a little messed up somehow, and the failures listed in http://boost.sourceforge.net/regression-logs/cs-Linux.html don't match those in http://boost.sourceforge.net/regression-logs/cs-Linux/developer/. Definitely vacation time now... John.

4 6

Re: [boost] Re: Pretty Good Initialization Library
by brangdon＠cix.compulink.co.uk 11 Jul '04

11 Jul '04

In-Reply-To: <cch4as$941$1(a)sea.gmane.org> andrewalex(a)hotmail.com (Andrei Alexandrescu $See Website for Email$) wrote (abridged): > I was worried more (only) about the order of evaluation. > > v += foo(), bar(); I don't think order of evaluation is sacred. However, I am also not keen on using comma for this. I'd rather use operator<<(). v << foo() << bar(); This is partly because comma is so small its easy to overlook, partly because it is used for so many other common things, and partly because I think the semantics of operator<<() fit better here. "Append these items to that stream or container, with conversion or formatting if appropriate." I would also be happy with: v << repeat(5) << 4; meaning: v << 4 << 4 << 4 << 4 << 4; and so forth. It doesn't bother me that: v = 1, 2, 3; has no direct equivalent. It becomes: v.clear(); v << 1 << 2 << 3; Presumably you'd be content with operator<<() in that it doesn't imply an order of evaluation. -- Dave Harris, Nottingham, UK

11 28

boost::function code size
by Vladimir Prus 11 Jul '04

11 Jul '04

Hello, I've became interested in how efficient code-size-wise boost::function is, so I wrote a small script which generates a function which calls boost::function object N times and finds the size of the generated function. The results are somewhat interesting and somewhat alarming (to me). On gcc 3.3 with -Os, each call to boost::function costs 147 bytes of code size. With -O3 it's about 166 bytes. On gcc 3.4 calls cost 203 bytes with -Os and between 220 and 240 with -O3. However, when boost::function is called 15 times, the inliner heuristics kick in and calls are no longer inlined -- meaning each call costs about 14 bytes. This is a good thing for 3.4, but still: 1. For 3.3 boost::function causes a serious code bloat. 2. Even for 3.4, I'm not sure how it will perform if calls are done in several modules. Or how the heuristics will work on non-trivial cases: if they use the % of size increase then on large modules boost::function inlining can cost much more. Given that, IIUC, boost::function has to do indirect call somewhere anyway, I'm not sure inlining is such a good idea. Maybe some of the methods should be declared out-of-line, so that compiler don't try to inline them? - Volodya

2 3

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > On Jul 9, 2004, at 11:00 PM, Glen Knowles wrote: > > >> <nod> I just implemented lock_both::lock two ways: Once > just keep > >> try-locking both ways, and once locking in the order of > the addresses > >> of the locks (with only two locks in the test, this was a safe > >> operator<). My test looks like: > > > > The problem case for spinning is when one thread gets the locks and > > the holds them for a non-trivial length of time. During > that time the > > other, spinning thread, just wastes cpu as fast as it can. > This just > > gets magnified as more threads are involved. > > You are describing a spin-lock, but not lock_both (except for > a theoretical and unlikely scenario). Yes, I didn't think it through all the way. Glen

1 0

RE: [boost] Re: Re: Re: Pretty Good Initialization Library
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Vladimir Prus [mailto:ghost@cs.msu.su] > > As Andras Erdei the gap between people who know about special > properties of operator(), and those who know that overloaded > version does not have that properties is very, very narrow. FWIW, I knew that a comma was a sequence point from experience with C but didn't know (never thought about) that it lost that property when overloaded in C++. Glen

1 0

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Matt Hurd [mailto:matt.hurd@gmail.com] > > Holding multiple locks is pretty common and necessary. If > you can guarantee they will always be acquired in the same > order they will not deadlock. It is necessary. :) > > AFAIK r/w locks only makes sense if you're going to hold read locks > > for a period of time, otherwise you're better off just > using a regular mutex. > > Concurrency may be better with shared access. > > The most common case for me is for collections. Multi-read > might be quite important to your application's concurrent performance. My logic is that using a read lock only improves concurrency over exclusion for that period of time that you hold the lock. If that period is short any improvement will likely be insignificant next to what you paid for hitting the memory barrier in either case. Of course, YMMV :) Glen

1 0

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > On Jul 9, 2004, at 7:10 PM, Glen Knowles wrote: > >> Without try locks, lock_both can't be made to work without risking > >> deadlock. > > > > Lock_both can be made to work with try locks? Either you > have a way to > > deterministicly set the order you lock the mutexes or you have > > problems. You can avoid deadlocking with try lock, but you > will fail > > to get the pair of locks in cases were you would have gotten it by > > waiting. I suppose you could just keep try-locking both > ways until you > > get it, but that's not good for performance. :) > > Well actually keep try-locking both ways is what I've been > doing. I'd agree with you that in a heavily contested > context, performance could theoretically suffer arbitrarily badly. > > > One solution to this problem would be mutex::operator< > > <nod> I just implemented lock_both::lock two ways: Once > just keep try-locking both ways, and once locking in the > order of the addresses of the locks (with only two locks in > the test, this was a safe operator<). My test looks like: The problem case for spinning is when one thread gets the locks and the holds them for a non-trivial length of time. During that time the other, spinning thread, just wastes cpu as fast as it can. This just gets magnified as more threads are involved. Glen

2 1

Boost sandbox
by Edward Diener 10 Jul '04

10 Jul '04

How does one access files in the Boost sandbox ? I am particular interested in libraries that have been reviewed and approved after the 1.31 release. When I get the latest Boost from CVS I do not see those libraries there. I am assuming they are somewhere, perjaps in the sandbox. How can I get them to try them out before the next release of Boost ?

2 3

Latest CVS doc links broken
by Edward Diener 10 Jul '04

10 Jul '04

The documentation links for lambda and thread in the latest Boost CVS do not go to a valid page.

1 0

[regression] Link failures for intel-win32-7.1-vc6-stlport-4.5.3
by Rene Rivera 10 Jul '04

10 Jul '04

Before John Maddock left on vacation, lucky him, he asked me to look into how to fix the problems with linking failing under some circumstances for this toolset in the regression tests. His supposition was that the auto-linking was not generating the correct name for linking, and that we needed to fix either the auto-linking or the build to be consistent about the naming. In looking at what is failing, as compared to what is not failing, my conclusion differs. The problem is that the failing tests are using auto-linking at all. As according to John himself one should not use it in the regression tests: "Please note however that this Jamfile will only build with compilers that do actually support auto-linking, so it should not be added to the regular regression tests." (http://boost.org/more/separate_compilation.html#testing) -- And the tests in question, signals, accidentally use both auto-linking and direct linking. There are two ways of fixing this problem: a) I automatically and globally <define>BOOST_ALL_NO_LIB=1 for all targets within Boost, or, b) We change individually each test that uses an auto-link enabled library to <define>BOOST_ALL_NO_LIB=1 I'm currently leaning towards (b), even if it is more work, as it has less chances of breaking other tests and/or the regular builds of examples and the libraries themselves. Comments? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 4

Proposed patch to config/compiler/visualc.hpp
by Michael Glassford 10 Jul '04

10 Jul '04

Two minor changes for WinCE compatibility, to be used by Boost.Threads. I can commit the changes myself, but didn't want to mess with the config files without bringing it up here first. Mike Index: boost/config/compiler/visualc.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/compiler/visualc.hpp,v retrieving revision 1.37 diff -u -r1.37 visualc.hpp --- boost/config/compiler/visualc.hpp 22 Jun 2004 12:33:06 -0000 1.37 +++ boost/config/compiler/visualc.hpp 6 Jul 2004 17:44:02 -0000 @@ -17,7 +17,7 @@ // turn off the warnings before we #include anything #pragma warning( disable : 4503 ) // warning: decorated name length exceeded -#if _MSC_VER <= 1200 // 1200 == VC++ 6.0 +#if _MSC_VER <= 1201 // 1200 == VC++ 6.0, 1201 == EVC4.2 #pragma warning( disable : 4786 ) // ident trunc to '255' chars in debug info # define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS # define BOOST_NO_VOID_RETURNS @@ -73,6 +73,11 @@ # define BOOST_NO_INTRINSIC_WCHAR_T #endif +#ifdef _WIN32_WCE +# define BOOST_NO_THREADEX +# define BOOST_NO_GETSYSTEMTIMEASFILETIME +#endif + // // check for exception handling support: #ifndef _CPPUNWIND

2 2

static_assert, documentation nit
by Glen Knowles 10 Jul '04

10 Jul '04

Near the beginning of the documentation on the website the example: Illegal use of COMPILE_TIME_ASSERTION_FAILURE<false> Should, I believe, read: Illegal use of STATIC_ASSERTION_FAILURE<false> Glen Knowles Centor Software Corporation

3 2

Problem with Linux test reports
by Joaquín Mª López Muñoz 10 Jul '04

10 Jul '04

Regression tests for Linux are updating OK every day, but the advanced developer and user reports seem to be stuck at Jul 5th. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > >>>> rw_mutex m; > >>>> > >>>> void invitation_for_deadlock() > >>>> { > >>>> read_lock r(m); > >>>> // ok to read > >>>> upgradable_read_lock ur(m); > >>>> r.unlock(); > >>>> write_lock w(ur); > >>>> // ok to write > >>>> } > >>>> > > > > It only deadlocks under a race, but I'm not sure it's scary. It's > > something I'm use to seeing in the presents of r/w locks. > > If r/w locks regularly encourage deadlocks, I am not anxious > to further pursue them. I'm not convinced of that however > (and hope I won't be). > I'm seeking a system which makes it easy to avoid deadlocks, > race conditions, and leaked locks. Admittedly any system can > be abused. > But a good system will naturally reduce accidental abuse, > while not necessarily preventing intentional abuse. Holding multiple locks regularly encourages deadlocks, if you don't do that you'll be okay. ;) Anything else I think you have to be careful. That's a big part of why I'm not so worried, I think the vast majority of cases only require one lock at a time, beyond that you're probably trying to do something complex. > There's not overhead in the lock, but in the rw_mutex to > support both read/write and upgradable_read. But hanging a > try_promote on multiple upgradable read locks really makes me > nervous. Doing so (imho) makes deadlock significantly more > likely (see my post with lock_both/transfer_lock example). > > Fwiw, here's what I'm seeing that is scaring me: > > A holds ur. > B holds r. > A waits for B to unlock r so it can unlock ur and lock w. > B waits for A to unlock ur so it can lock ur. Yes, multiple readers all trying to upgrade. What made it interesting to me is that its one of the few cases where a deadlock detector gets to kill multiple waiters. AFAIK r/w locks only makes sense if you're going to hold read locks for a period of time, otherwise you're better off just using a regular mutex. Glen

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > My intention with the read/write lock stuff was simply that > these guys needed to at least support try locks. That is > needed so that you can do assign-like locking between two objects: > > { > lock_both<write_lock, read_lock> l(a.mut(), b.mut()); > a = b; > } > > Without try locks, lock_both can't be made to work without risking > deadlock. Lock_both can be made to work with try locks? Either you have a way to deterministicly set the order you lock the mutexes or you have problems. You can avoid deadlocking with try lock, but you will fail to get the pair of locks in cases were you would have gotten it by waiting. I suppose you could just keep try-locking both ways until you get it, but that's not good for performance. :) One solution to this problem would be mutex::operator< Glen

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 10 Jul '04

10 Jul '04

From: Howard Hinnant [mailto:hinnant@twcny.rr.com] >On Jul 9, 2004, at 4:11 PM, Peter Dimov wrote: >>> rw_mutex m; >>> >>> void invitation_for_deadlock() >>> { >>> read_lock r(m); >>> // ok to read >>> upgradable_read_lock ur(m); >>> r.unlock(); >>> write_lock w(ur); >>> // ok to write >>> } >>> >>> It took me awhile to spot the deadlock in the above code. Does >>> anyone else see the above code as scary? (scary as in looks ok but isn't). >>> Or is the deadlock obvious to everyone else (and thus not scary)? >> >> Not scary, IMO, even if not obvious, because it always deadlocks, as >> soon as you attempt the "idiom". You can't miss it. > > I'm not following "always deadlocks". If only one thread enters, at > what point does it deadlock (assuming no other thread playing with m)? > Experimentally running through this on my prototype implementation > with a single thread isn't deadlocking. But perhaps my prototype is buggy? It only deadlocks under a race, but I'm not sure it's scary. It's something I'm use to seeing in the presents of r/w locks. I don't know where you left off, are you implementing single upgradeable or multiple upgradeables? If only one upgradeable can exist in the system at a time then, what would deadlock, will result in a failure to create a second upgradable lock, IIUC. You can always manufacture ways to deadlock, I'd still vote for just hanging a try/timed_promote() on all read locks. Unless perhaps there's overhead in upgradable_read_lock that isn't required in read_lock? Glen

2 1

Re: [boost] Re: Pretty Good Initialization Library
by brangdon＠cix.compulink.co.uk 09 Jul '04

09 Jul '04

In-Reply-To: <200407081913.i68JD5d00852(a)tesh.systems.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > I overstated the case. How many types will one have to overload > operator<< (and operator>>) for? The combinatorial explosion > (containers X types to use with the initialization library X 2) > will be overwhelming. You've lost me. Why does the choice of operator<<() instead of operator,() produce a combinatorial explosion of overloads? It's mostly just a change of name. > I still think of operator<< and operator>> as doing formatted I/O. Well, at one time we all thought it did bitwise shifts. -- Dave Harris, Nottingham, UK

2 1

CVS Commit issue
by Robert Ramey 09 Jul '04

09 Jul '04

I've got my issues re cygwin path for ssh access squared away. Now I want to check in some files. I'm using the book "Open Source Development with CVS" as a guide. I get to the point of commit and I get. Stuck again. It seems to me that this is something out of my control - or is it? Here is my screen dialog $ cvs -d:ext:ramey@cvs.sourceforge.net:/cvsroot/boost commit -m "initial check ramey(a)cvs.sourceforge.net's password:<password entered here> cvs commit: failed to create lock directory for `/cvsroot/boost/boost/boost/archive' (/cvsroot/boost/boost/boost/archive/#cvs.lock): No such file or directory cvs commit: lock failed - giving up cvs [commit aborted]: lock failed - giving up I would appreciate any help anyone has to offer. Robert Ramey

2 1

cvs access problems
by Robert Ramey 09 Jul '04

09 Jul '04

I'm trying to check in the serialization system and am having some problems. According to the sourceforge.net docs I need to "register" my host with my local ssh by logging in in the following manner. $ ssh -l ramey cvs.sourceforge.net Could not create directory '/home/Robert Ramey/.ssh'. The authenticity of host 'cvs.sourceforge.net (66.35.250.207)' can't be established. DSA key fingerprint is 02:ab:7c:aa:49:ed:0b:a8:50:13:10:c2:3e:92:0f:42. Are you sure you want to continue connecting (yes/no)? yes Failed to add the host to the list of known hosts (/home/Robert Ramey/.ssh/known_hosts). ramey(a)cvs.sourceforge.net's password: Last login: Thu Jul 8 22:22:39 2004 from 226-146.adsl2.netlojix.net Welcome to cvs1.sourceforge.net This is a restricted Shell Account You cannot execute anything here. Connection to cvs.sourceforge.net closed. $ Ssh seems to have difficulty creating/updated a file of known_hosts in my home directory. I'm using windows XP with cygwin shell. I've tried changing environmental variables $HOME, and others but nothing seems to make a difference. Does anyone have any suggestion. I realize that this isn't the best place to post this but I'm kind if desperate. Thank you for your patience. Robert Ramey

4 6

Re: lightweight mutex
by Dan 09 Jul '04

09 Jul '04

Just a note on the lightweight mutex for windows OS using Interlocked operations: I had one like this before (came with doug lee's allocator) and I ran some benchmarks and saw a ~10% improvement in performance in a non-contention situation. Now that benchmark may or may not have been valid, it's too long ago for me to say with certainty, but it raises the question, what are the numbers here? Also one does not need to use a spin lock on a ref counted implementation. A much faster (and safer) way to do that is just using InterlockedIncrement and InterlockedDecrement when changing the ref count. I beleive this is what most popular ref counting implementations use.

3 2

[Boost-bugs] [ boost-Bugs-988124 ] Borland compiler error with Pool, boost::pool_allocator
by SourceForge.net 09 Jul '04

09 Jul '04

Bugs item #988124, was opened at 2004-07-09 10:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=988124&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David W. Thomas (davidwt) Assigned to: Nobody/Anonymous (nobody) Summary: Borland compiler error with Pool, boost::pool_allocator Initial Comment: This Borland compiler error occurs with boost release versions 1.30.2 and 1.31.0. It also occurs with the latest CVS checkout as of July 9, 2004. I've tried this on two Win2000 computers with totally different hardware (Intel, AMD). Borland compilers from Borland Builder5 and from Borland BuilderX both generate an internal compiler error with a typedef of pool_allocator<int>. The source code file t.cpp contains: #include <boost/pool/pool.hpp> typedef boost::pool_allocator<int> node_alloc; Here is a copy of the DOS window for the two compiles: D:\>c:\borland\CBUILDER5\BIN\bcc32 - I\src.misc\boost;c:\borland\CBUILDER5\include t.cpp Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland t.cpp: Fatal F1004 t.cpp 2: Internal compiler error at 0x46f530 with base 0x400000 Fatal F1004 t.cpp 2: Internal compiler error D:\>c:\borland\CBUILDERX\BIN\bcc32 - I\src.misc\boost;c:\borland\CBUILDERX\include t.cpp Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland t.cpp: Fatal F1004 t.cpp 2: Internal compiler error at 0x4394f6 with base 0x400000 Fatal F1004 t.cpp 2: Internal compiler error ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=988124&group_i… ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Question about Boost.Random
by Kris Thielemans 09 Jul '04

09 Jul '04

Hi Anders you probably should read my email on this of a few days ago. The simple answer is to use typedef boost::variate_generator<engine_t&, distribution_t> rng_t; (i.e. with ref) It all makes sense, it's just hard to get from the doc in my opinion. Kris > // The following program illustrates a problem in Boost.Random. > > // Is this the desired behavior? > > // If so, what is the reason for this? > > // I use Boost version 1.31 and GCC version 3.3.3 on Suse 9.1 > > #include <vector> > #include <algorithm> > #include <boost/random.hpp> > > // Definition of the random number generator > typedef boost::mt19937 engine_t; > typedef boost::uniform_int<int> distribution_t; > typedef boost::variate_generator<engine_t, distribution_t> rng_t; > > int main() > { > const unsigned int N = 13, A = 0, B = 1000; > std::vector<int> run1(N), run2(N), run3(N); > > // Generate some random integers > { > engine_t engine; > distribution_t distribution(A,B); > rng_t rng(engine, distribution); > std::generate(run1.begin(), run1.end(), rng); > } > > // Verify that I get the same sequence if I start again > { > engine_t engine; > distribution_t distribution(A,B); > rng_t rng(engine, distribution); > std::generate(run2.begin(), run2.end(), rng); > } > > // It appears that the generator restarts for each generate, since > // the generate algorithm creates a copy of the functor so that > // its state is lost > { > engine_t engine; > distribution_t distribution(A,B); > rng_t rng(engine, distribution); > std::generate(run3.begin(), run3.begin()+N/2, rng); > std::generate(run3.begin()+N/2, run3.end(), rng); > } > > // For me it would seem more natural if the engine class would be a > // singleton, so that there can be only one object of any particular > // random generator engine type. > > // Our purpose for using random numbers is to simulate physical processes. > // I can't think of a case when there would be a need for several random > // engines, even if there can of course be many different random > // distributions in an application. > > // Having the same random number sequence in different parts of a > simulation > // can probably create very strange behaviour, since the numbers from the > // different engines of the same type will be perfectly correlated. > > // Perhaps other applications have use of several random engines? > > for(unsigned i=0; i<N; ++i) { > if(i==N/2) > std::cout<<"Halfway there!"<<std::endl; > std::cout > <<run1[i] > <<" == "<<run2[i] > <<" == "<<run3[i] > <<std::endl; > } > > return 0; > } > > // Anders Edin > // Sidec Technologies AB > >

1 0

Re: [ublas-dev] Re: Boost Mathematicians
by Jeremy Graham Siek 09 Jul '04

09 Jul '04

Hi Paul, Yes, you've got the idea. The following document shows one such attempt to construct a system of traits for algebraic concepts: http://www.cs.rpi.edu/~schupp/entries/SOFTWARE/simpl/doc/AlgCpp.pdf also, more information is available starting at: http://www.cs.rpi.edu/~schupp/entries/SOFTWARE/simpl/ Cheers, Jeremy On Jul 7, 2004, at 7:32 PM, Paul C. Leopardi wrote: > Jeremy, Dave, > I think I get it. See below. > Best regards > On Thursday 08 July 2004 02:25, David Abrahams wrote: > > Jeremy Graham Siek <jsiek(a)osl.iu.edu> writes: > > > group_traits<T>::is_commutative > > is_commutative_group<T>::type > > is_commutative_group<T>::type::value > > OK, for a type where you have one operation (a group). > For a two operation type, I suppose you would then want > > is_ring<T>::type > is_ring<T>::type::value > > is_commutative_ring<T>::type > is_commutative_ring<T>::type::value > > Along these lines, you could build a header file called > arithmetic_traits.hpp > or something similar. The object of this file would be to describe > some of > the semantics of operator+, operator* and possibly other operators > when used > with various types. Eg. you could have say > > is_algebra< framed_multi<T,L,H>, T>::type > is_algebra< framed_multi<T,L,H>, T>::scalar_type > > This header would also be used to define the zero element of addition > and the > identity element of multiplication, if it exists. > > Once this header is established, you could build template libraries > which > perform arithmetic according to the axioms embodied in the traits. > Such a > library would not eg. assume that multiplication is commutative, it > would > check this at compile time. > > Note that there would also need to be a distinction between > approximate and > exact arithmetic. This especially affects associativity, where eg. > addition > of real numbers behaves differently from addition of floating point > numbers > due to loss of precision. eg. > http://h18009.www1.hp.com/fortran/docs/vf-html/pg/pg1round.htm > http://www.ibiblio.org/pub/languages/fortran/ch4-6.html > > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > <lrec_companion_043004.gif> > <l.gif> > > Yahoo! Groups Links > > • To visit your group on the web, go to: > http://groups.yahoo.com/group/ublas-dev/ > > • To unsubscribe from this group, send an email to: > ublas-dev-unsubscribe(a)yahoogroups.com > > • Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________

1 0

boost::posix_time::ptime constructor from special values? ( eg, not_a_date_time )
by Richard Reitmeyer 09 Jul '04

09 Jul '04

Hello. Thanks for all your work in the boost::date_time code. It's very useful. I've got a question about constructing a ptime from special values. The documentation says it works, but I can't find the appropriate constructor in ptime.hpp. (I'm using 1.31.0.) Is this a bug, or am I missing something? Richard

2 1

Partially specializing less<> with nested template class
by David B. Held 09 Jul '04

09 Jul '04

This is what I would like to do: template <class P1, class P2> struct sp { template <typename T> struct nested { }; }; template <typename T> struct less; template <class P1, class P2, typename T> struct less<sp<P1, P2>::nested<T> > : binary_function<...> { bool operator()(...); }; However, it doesn't work. From my research, it seems that the problem is that T is in a non-deduced context, but I don't see why that would be an issue, since this is how I expect it to get instantiated: less<sp<p1, p2>::nested<int> > comp; Thus, I don't see any deduction as being necessary, but obviously I don't exactly understand how to get what I want. Dave

4 16

[regression] XSLT reports...
by Rene Rivera 09 Jul '04

09 Jul '04

For the regression reports that are generated with XSLT there is a rather annoying setting the master.css style sheet used for them. For some of the styles, legend, comment, and header-table, a fixed width attribute is used. If the width was small it would not be a problem. But the width is set to 800px. Which means that most people will end up scrolling left and right to see the complete content. If someone would nice enough to change these to a relative value, like 80%, it would be much appreciated. I'd do it myself, but I don't know if me changing the master.css in CVS has any effect on the test machines. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 2

[ref] small problem with docs
by Jonathan Turkanis 09 Jul '04

09 Jul '04

The synopsis for unwrap_reference, at http://www.boost.org/doc/html/class.boost.unwrap_reference.html, is as follows: template<typename T> class unwrap_reference { public: // types typedef unspecified T; }; The second to last line should be 'typedef unspecified type;' Jonathan

3 2

RE: [boost] Re: VC7.1 Building...
by Brian Carlson 09 Jul '04

09 Jul '04

>>If you want to build for vc7.1 you should use vc7.1. > > I did (bjam -sTOOLS=vc7.1 stage) and I get the following error: > > Vc7.1-tools.jam No such file or directory. ^ It's case sensitive. I did a search of the boost directory, and only a vc7-tools.jam, no vc7.1-tools.jam. I think that there is no jam file for vc7.1 in boost 1.29

2 1

RE: [boost] min, max, GCC 2.95.3, and STLport
by Rozental, Gennadiy 09 Jul '04

09 Jul '04

Why subject configuration still failing on min/max according to Linux regression? Gennadiy.

3 2

Patch for Boost.Threads
by Synge Todo 09 Jul '04

09 Jul '04

Dear Boosters, I found that the recent changes made on libs/thread/src/exceptions.cpp break the SGI MIPSpro compiler. Could somebody apply the following patch? Thank you in advance. Best regards, Synge Todo diff -crN boost.orig/libs/thread/src/exceptions.cpp boost/libs/thread/src/exceptions.cpp *** boost.orig/libs/thread/src/exceptions.cpp Wed Jul 7 02:20:55 2004 --- boost/libs/thread/src/exceptions.cpp Thu Jul 8 20:15:19 2004 *************** *** 12,17 **** --- 12,18 ---- #include <boost/thread/detail/config.hpp> #include <boost/thread/exceptions.hpp> + #include <cstring> #include <string> # ifdef BOOST_NO_STDC_NAMESPACE

2 2

RE: [boost] min, max, GCC 2.95.3, and STLport
by Rozental, Gennadiy 08 Jul '04

08 Jul '04

> Are there any other failures regarding min/max you've noticed, or is it just the three tests I've mentioned? As far as I see everything still failing: See here http://tinyurl.com/yq9rw Gennadiy.

2 1

BOOST on Integrity RTOS
by Gaetano Mendola 08 Jul '04

08 Jul '04

Hi all, anyone know if the boost library is available for Green Hills C++ compiler ? I need to port an application that use the boost library on a Integrity RTOS ( that use that compiler ). Regards Gaetano Mendola

1 0

RE:RE: RE: [boost] Does anyone have an is_virtual_base_and_derived ?
by Robert Ramey 08 Jul '04

08 Jul '04

I'm beginning to see that now. In my test case the situation has been much confused by the fact that b1 has/didn't have a virtual destructor which in turn makes it possible/impossible. Oh and running on different compilers in debug/release mode changed behavior as well which left me totally confused. So I'm working through my confusion. >> > I wrote that very thing a year or so ago for the purpose of >> testing if a >> > base pointer type can be statically downcast to a derived type. >> >> My problem exactly ! >I should warn you that this isn't quite enough information to test for >static downcastability in all cases. Take the following example: >struct b1 {}; >struct b2 : b1 {}; >struct b3 : virtual b2 {}; >Here, b1 is not a virtual base of b3, but a downcast from b1* to b3* is >still impossible. I don't believe there is any way to test for this case >without compiler assistance. Robert Ramey

1 0

RE: [boost] Re: Re: VC7.1 Building...
by Brian Carlson 08 Jul '04

08 Jul '04

> > >I would start over if I were you. Open a Command Propmpt window. Change > > >directory to you boost_1_31_0 directory. Type the following _exactly_ > > >as > > >shown: > > > > > > bjam -sTOOLS=vc7.1 stage > > > > I did, but I'm using 1.29, not 1.31 That might be the problem....hmm > I'd think bjam changed significantly since 1.29? I don't think the build > instructions noted above are valid for pre 1.3x. Any reason your not using > 1.31? I'm using a third party api, that requires boost. I don't have a direct requirement. I wanted to move to vc7.1, and that's when I started to have link problems, "unresolved external... function0". I hoped that rebuilding 1.29 in vc7.1 would take care of the problem. I'm getting ready to try the api with 1.31. We'll see. Any thoughts would be arreciated. Thanks, Brian

2 1

RE: [boost] FYI: Trolltech's new generic containers
by Max Khesin 08 Jul '04

08 Jul '04

Hi Neal, What do you like about these? -----Original Message----- From: Neal D. Becker [mailto:ndbecker2@verizon.net] Sent: Thursday, July 08, 2004 2:36 PM To: boost(a)lists.boost.org Subject: [boost] FYI: Trolltech's new generic containers This may be of some interest: http://doc.trolltech.com/4.0/containers.html _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Re: [boost] Re: Pretty Good Initialization Library
by brangdon＠cix.compulink.co.uk 08 Jul '04

08 Jul '04

In-Reply-To: <200407072103.i67L3Jk28273(a)tesh.systems.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > > v << foo() << bar(); > > I don't like that. It suggests formatted insertion rather than > initialization. It's not intended to be initialisation. It does a push_back(), so you can do it at any time and not just on empty vectors. I guess I'd pick a different name for the library, but as written that includes += so it too is not just for initialisation. As I said, I don't think formatting is an essential characteristic of operator<<(). It happens to be necessary for streams because they are text oriented. The serialisation library uses operator<<() without formatting. > As you point out, conversion is possible, but one can't overload > operator<< to customize the initialization. Why not? vector<Foo> &operator<<( vector<Foo> &v, const Bar &bar ) { return v << bar.toFoo(); // Or whatever conversion you want. } Or whatever the right types are. > Thus, it doesn't fit neatly with IOStreams. It's not polymorphic with them, but I think it fits about as neatly as the serialisation library. -- Dave Harris, Nottingham, UK

2 1

RE: [boost] Re: VC7.1 Building...
by Brian Carlson 08 Jul '04

08 Jul '04

>You might want to limit posts to plain text, whatever email format your >using defeats the auto-original-indent capabilities for Outlook Express. >Also directly reply to messages that you are reading. Many use the >gmane.org >newsreader interface which maintains message thread integrity. This is set to plain text, I'm using Outlook. Hopefully this works better. > I don't have a vc7.1-tools.jam file. And I have vc7.0 and vc7.1 > I've never heard of this file, and don't think there is one. When you run bjam -sTOOLS=XXX It takes the XXX and appends -tools.jam to find the .jam file for building for the specific compiler. > Your building for vc7.0, I'm not sure what the -a is. -a is rebuild all, even if current. >If you want to build for vc7.1 you should use vc7.1. I did (bjam -sTOOLS=vc7.1 stage) and I get the following error: Vc7.1-tools.jam No such file or directory. >I would start over if I were you. Open a Command Propmpt window. Change >directory to you boost_1_31_0 directory. Type the following _exactly_ as >shown: > > bjam -sTOOLS=vc7.1 stage I did, but I'm using 1.29, not 1.31 That might be the problem....hmm Thanks, Brian

3 2

FYI: Trolltech's new generic containers
by Neal D. Becker 08 Jul '04

08 Jul '04

This may be of some interest: http://doc.trolltech.com/4.0/containers.html

1 0

RE: RE: [boost] Does anyone have an is_virtual_base_and_derived ?
by SRobb＠reflectionsinteractive.com 08 Jul '04

08 Jul '04

> > I wrote that very thing a year or so ago for the purpose of > testing if a > > base pointer type can be statically downcast to a derived type. > > My problem exactly ! I should warn you that this isn't quite enough information to test for static downcastability in all cases. Take the following example: struct b1 {}; struct b2 : b1 {}; struct b3 : virtual b2 {}; Here, b1 is not a virtual base of b3, but a downcast from b1* to b3* is still impossible. I don't believe there is any way to test for this case without compiler assistance. Testing for a virtual base happened to be good enough for us though, so we went with it; it may well be enough for your needs too.

1 0

Proposal: Minimalist ScopeGuard
by Jonathan Turkanis 08 Jul '04

08 Jul '04

Hi All, I've uploaded a very simple version of Andrei and Petru's ScopeGuard to the files section: http://groups.yahoo.com/group/boost/files/scope_guard.zip. It's only smart enough to handle cleanup functions or function objects with the signature 'void f()'; more complex cleanup is easy with Bind or Lambda. There are two object generators: - make_guard returns a scope guard which propagates exceptions - safe_guard returns a scope guard which catches and ignores exceptions Similarly, there are two macros - BOOST_SCOPE_GUARD declares an anonymous scope guard which propagates exceptions - BOOST_SAFE_GUARD declares an anonymous scope guard which catches and ignores exceptions Best Regards, Jonathan //------------------Example--------------------// #include <iostream> #include <boost/bind.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> #include <boost/scope_guard.hpp> void goodbye() { std::cout << "goodbye\n"; } void crash() { throw 0; } struct T { void goodbye() { std::cout << "goodbye\n"; } }; // // Expected output: // hello // goodbye // goodbye // goodbye // goodbye // goodbye // int main() { using namespace boost; T t; // Scope guard which invokes t.goodbye(). scope_guard g1 = make_guard(boost::bind(&T::goodbye, t)); // Scope guard which invokes goodbye(). scope_guard g2 = make_guard(goodbye); // Scope guard which executes std::cout << "goodbye\n". scope_guard g3 = make_guard( std::cout << boost::lambda::constant("goodbye\n") ); // Scope guard which invokes crash() in a try-catch block. scope_guard g4 = safe_guard(crash); // Scope guard which invokes crash(). scope_guard g5 = make_guard(crash); g5.dismiss(); // Scope guard which invokes goodbye(). BOOST_SCOPE_GUARD(goodbye); // Same. (Shows that generated variable names are working.) BOOST_SCOPE_GUARD(goodbye); // Scope guard which invokes crash() in a try-catch block. BOOST_SAFE_GUARD(crash); std::cout << "hello\n"; }

1 0

[multi_index] scope_guard
by Jonathan Turkanis 08 Jul '04

08 Jul '04

Hi Joaquín, I'm looking at your version of scope_guard in the current CVS. I'm intersted to know why you didn't include boostified versions of the macros ON_BLOCK_EXIT from Andrei and Petru's original article. Was it just because you didn't need it or because you found it objectionable for some reason? Also, I read that you were disappointed with its performance, and I see that you only use it for checking invariants, when enabled. Do you plan on keeping it in Boost.MultiIndex? Have you considered submitting it for fast track review? Jonathan

3 6

RE: [boost] Re: VC7.1 Building...
by Brian Carlson 08 Jul '04

08 Jul '04

I just tried the vc71 option. But no jam file for that either. Am I suppose to create my own vc71-tools.jam file (copy or copy&edit)? What changes are needed? Thanks, Brian -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Russell Hind Sent: Thursday, July 08, 2004 9:56 AM To: boost(a)lists.boost.org Subject: [boost] Re: VC7.1 Building... Have you tried bjam -sTOOLS=vc71 I'm pretty sure that is what I used but I do have a vc7.1-tools.jam file with boost-1.31.0 Russell Brian Carlson wrote: > I don't have a vc7.1-tools.jam file. And I have vc7.0 and vc7.1 > installed on my machine. So this is what I did... > > bjam -sTOOLS=vc7 -a > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

RE: RE: [boost] Does anyone have an is_virtual_base_and_derived ?
by SRobb＠reflectionsinteractive.com 08 Jul '04

08 Jul '04

> My problem exactly ! > > So I think this is what I need. Just to prove once again that no good deed > goes unpunished - > > a) at a very minimum I want to add a boost copyright license and for that I > would need your name which wasnn't on your post. Steve Robb is my name. I've updated my profile so that it should hopefully now appear on these mails. > b) any chance of this getting "boostified" with a couple of tests an maybe a > micro-review?. Certainly can. I'm only capable of testing it with a few compilers though: VC++s 6, 7 and 7.1, and GCCs 2.95 and 3.2. > c) I notice that the type_traits already in the library are much - much more > elaborate due to the variations in compilers. Any chance of this getting > subjected to this kind of treatment? Actually, this leads to an issue we've had with compile times. The sheer volume of code included in the Type Traits headers to support all compilers lead me to re-implement a significant proportion of them in a 'minimal' fashion. Our build times almost halved as a result. Obviously our traits code doesn't cover the same body of compilers that Boost supports, but perhaps a rethink of the structure of the Type Traits library may be in order. To take a typical example like <boost/type_traits/is_same.hpp>, which can be implemented in terms of partial specialisation in a few lines on the majority of common compilers, still causes 59 headers (on my current configuration) on VC7.1. From this point of view, I prefer Loki's system of having a 'reference' copy of the traits class which fully-compliant compilers are directed to, with non-compliant compilers having their own implementations in separate files. I'm sure this issue has been raised here already, but I think it's worth reiterating, as it can save many man hours of wasted time.

2 1

VC7.1 Building...
by Brian Carlson 08 Jul '04

08 Jul '04

I don't have a vc7.1-tools.jam file. And I have vc7.0 and vc7.1 installed on my machine. So this is what I did... bjam -sTOOLS=vc7 -a How can I verify that it built with the vc7.1 compiler. Or am I wrong in using vc7 for the tools? Thanks, Brian

3 2

[Thread] [Patch] gcc-3.4.x issues
by Jürgen Hunold 08 Jul '04

08 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! The attached patch fixes some gcc-3.4.x errors and warnings: boost/thread/tss.hpp: libs/thread/src/tss.cpp: gcc complains about extra token after #endif. I've added the needed c++ comments. boost/thread/detail/lock.hpp: Typo in member template. Yours, Jürgen - -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7UYsljbJ/LLrxrYRAnyXAKC3rjawDEOJgRU1xQoHZqnmD7BzqgCgryyO 1Lpe5xjEQE/lhw8txYA+6Ww= =3DQI -----END PGP SIGNATURE-----

3 2

[BGL] [Patch] graph/dijkstra_shortest_paths.hpp
by Jürgen Hunold 08 Jul '04

08 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! in revision 1.38 Jeremy cvs log : "removed inf parameter for the no_init version of Dijkstra's" but forgot to change the call of the no_init version at line 211. The following patch corrects this. Yours, Jürgen - -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5Q4IljbJ/LLrxrYRApJcAKDeWInG0yNhEtT3Nhik0J4KqojT1wCfY5gE 5+1FQmkTgp7Qw8L8yNiqu/U= =L0GY -----END PGP SIGNATURE-----

2 2

[Bind] Increasing the max number of arguments bind supports?
by Doug Gregor 08 Jul '04

08 Jul '04

We just ran into a need for passing 12 arguments to boost::bind(), which only supports up to 9 arguments. Is there any way to (easily?) increase this number? With Function, one can just set BOOST_FUNCTION_MAX_ARGS to change the value; does/could Bind have something similar? Doug

3 4

[filesystem + iterator] directory iterator problem
by Vladimir Prus 08 Jul '04

08 Jul '04

There's a bug report on sourceforge: https://sourceforge.net/tracker/index.php?func=detail&aid=937606&group_id=7… which boils down to the fact that directory_iterator it(...); path p = *it++; does not work correctly. The exact problem is that the above line return a copy of the iterator, and increments 'it', but both iterators have shared_ptr to the same internal structure, so by time user deferences the copy, it gets the next file in the directory. The filesystem lib sources contain the following comment: The *r++ requirement doesn't appear to apply to the new single_pass_traversal category Thus I'm leaving the proxy out pending confirmation from the N1477 authors I'm not sure I understand that. It seems that *r++ should work, since signle pass iterator requires that r++ should work and return object of type X (call it r2), and the reabable iterator requires that *r2 should work. Am I wrong? And BTW, don't the above requirements mean r++ cannot return a proxy object, but only a real copy of the iterator? - Volodya

2 25

result_ofOp, operator should be a template parameter
by Andy Little 08 Jul '04

08 Jul '04

An example that I think demonstrates the superiority of this: binary_operation<A,Op,B>::result_type result; over this: result_of_plus<A, B>::type result; in this directory: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/source/ array_calcs.hpp and array_calcs.cpp. The example shows an expression template for arrays based on the examples in: http://osl.iu.edu/~tveldhui/papers/techniques/ (BTW this is part of my next distro so no guarantee it works in pqs-1-01-04 , though should be ok.) Specifically making the operator a template parameter makes it generic IMHO and much reduces the work required. If an expression is required in "typeof" then it cant work generically , unless operators are allowed as template params And a generic "placeholder"operator param is included. (Simple promotion is inadequate for udts) Simple useage of binary_operation described here: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/binary_operation… regards Andy Little

4 24

Review Wizard Needed
by David Abrahams 08 Jul '04

08 Jul '04

After pioneering the role of Boost Review Wizard, and doing a darned fine job of it, Thomas Witt has resigned, leaving this important position open. The moderators are now accepting applications for his replacement. The responsibilities of the review wizard are listed here: http://www.boost.org/more/formal_review_process.htm#Wizard. If you're interested in making a crucial contribution to the future of Boost, please send a short note to boost-owner(a)lists.boost.org with a sentence or two about why you'd like to be the next Review Wizard. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] Generalizing the shared_ptr
by Hurd, Matthew 08 Jul '04

08 Jul '04

> Behalf Of Maciej Sobczak <snip bits everywhere> > Hi, Hi Maciej, > Is it possible to achieve the same results with the existing Boost > libraries? I think so. Have a gander at http://www.boost.org/libs/smart_ptr/sp_techniques.html and see if that meets cooks your goose. Regards, Matt Hurd. _________________ +61.2.8226.5029 hurdm(a)sig.com Susquehanna _________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

is_polymorphic type_trait question
by Robert Ramey 07 Jul '04

07 Jul '04

I have the following little test program #include <boost/static_assert.hpp> #include <boost/type_traits/is_polymorphic.hpp> struct vbase { }; struct derived : public virtual vbase { }; // VC 7.1, borland 5.51 and Commeau trap here (gcc 3.2 doesn't trap here!) BOOST_STATIC_ASSERT(boost::is_polymorphic<derived>::value); // everything including gcc traps here ! BOOST_STATIC_ASSERT(boost::is_polymorphic<vbase>::value); int main(int argc, char *argv[]) { } This suggests to me that is_polymorphic returns true for a class derived virtually from a base class under the gcc compiler even though the base class has no virtual function!

2 1

Re:RE: [boost] Does anyone have an is_virtual_base_and_derived ?
by Robert Ramey 07 Jul '04

07 Jul '04

SRobb(a)reflectionsinteractive.com > I wrote that very thing a year or so ago for the purpose of testing if a > base pointer type can be statically downcast to a derived type. My problem exactly ! So I think this is what I need. Just to prove once again that no good deed goes unpunished - a) at a very minimum I want to add a boost copyright license and for that I would need your name which wasnn't on your post. b) any chance of this getting "boostified" with a couple of tests an maybe a micro-review?. c) I notice that the type_traits already in the library are much - much more elaborate due to the variations in compilers. Any chance of this getting subjected to this kind of treatment? I'm now testing this on my problem. Robert Ramey

1 0

Boost Mathematicians
by Tom Brinkman 07 Jul '04

07 Jul '04

What is the current status of all Boost mathmatical, statistical and econometric libraries currently in development? The collection of boost math libraries that are currently included in the library are world-class and provide a wonderful foundation to build-upon. However, many areas of advanced statistical and mathmatical inference are not currently being addressed by any of the boost libraries. Is there currently a way for those boost developers with a background in mathmatics to coordinate their efforts. If not, why not? Lets get such a discussion started. A continued and regular dialog of mathmatics as it relates to boost library development would be of great use, primaryily to avoid overaping our efforts. If your a mathmetician and agree with me that boost is a great foundation to build-upon, let the group/me know. Points for Discussion: 1) We should keep a seperate list of boost::math libraries that are currently under development and provide a forum for advanced discussions. How can we do this? 2) We need a way to attract the best mathmaticians in the world. How can we make the boost libraries an even more attractive development platform for the mathemiticians? 3) We should create a list of mathmatical algorithims and libraries that are needed. 4) We need some very basic boost specific math-tutorials for our future mathemiticans and potential library writers. 5) We need to advertise to the development community about how strong of a foundation boost is for mathmatical library development. In short, lets tell the world that this is the premiere place for advanced mathmatical library development, as I believe that it could be. Comments? Regards, Tom Brinkman __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

23 70

RE: [boost] Re: [utility] boost::reset
by jhopkin＠reflectionsinteractive.com 07 Jul '04

07 Jul '04

Daniel Frey wrote: > jhopkin(a)reflectionsinteractive.com wrote: > > The STL implementation I have been using seems to allocate a buffer on first > > insertion into any container of a given type, and frees it only when it > > feels like it (often on program shut-down). > > Sounds like a pool allocator. Question: Does .clear() for your STL > return the buffer to the pool or is it still bound to the instance? What > happens in case of the .swap()-trick? I believe .clear() and the swap trick do what's expected per instance. Specifically for vector, clear generally won't release any memory to the pool; the swap trick releases it all. James Hopkin

2 1

RE: [boost] Does anyone have an is_virtual_base_and_derived ?
by SRobb＠reflectionsinteractive.com 07 Jul '04

07 Jul '04

I wrote that very thing a year or so ago for the purpose of testing if a base pointer type can be statically downcast to a derived type. I don't claim to have tested all permutations of its usage, but it certainly worked on the cases I was testing it with. However, it does have the unfortunate side-effect of generating an 'ambiguous base' warning on the later GCCs every time it is used with a class which inherits another non-virtually. (though the traits class still gives the correct answer) If anyone can find a way of preventing this warning, or even an alternate implementation, I'd be glad to hear it. Here is my basic implementation: #include <boost/config.hpp> #include <boost/type_traits/is_convertible.hpp> namespace is_virtual_base_and_derived_detail { #ifdef _MSC_VER #pragma warning(push) #pragma warning(disable : 4250) #endif template <typename BaseImpl, typename DerivedImpl> struct tester : public DerivedImpl, virtual public BaseImpl { tester(); tester(const tester&); }; #ifdef _MSC_VER #pragma warning(pop) #endif template <typename Base, typename Derived, bool IsBaseAndDerived> struct impl; template <typename Base, typename Derived> struct impl<Base, Derived, true> { BOOST_STATIC_CONSTANT(bool, value = sizeof(tester<Base, Derived>) == sizeof(Derived)); }; template <typename Base, typename Derived> struct impl<Base, Derived, false> { BOOST_STATIC_CONSTANT(bool, value = false); }; } template <typename Base, typename Derived> struct is_virtual_base_and_derived : is_virtual_base_and_derived_detail::impl<Base, Derived, boost::is_convertible<Derived*, Base*>::value> { }; template <typename T> struct is_virtual_base_and_derived<T, T> { BOOST_STATIC_CONSTANT(bool, value = false); }; -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Tuesday, July 06, 2004 6:01 PM To: boost(a)lists.boost.org Subject: [boost] Does anyone have an is_virtual_base_and_derived ? Type traits includes: ::boost::is_base_and_derived<T,U> Does anyone have a version that might be called is_virtual_base_and_derived<B, D> which would return true iff D is derived virtually from B ? Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

regression tests on irix
by Toon Knapen 07 Jul '04

07 Jul '04

I'm trying to get the regression tests working again on SGI/Irix but I fail to build the html tables. Apparantly the compiler_status tool is looking for a Jamfile in the wrong place. Anybody a clue what could be happening (failing command and its output in attachment) toon generating html tables: /disk2/home/tk/boost_regression/boost/tools/regression/build/run/compiler_status --comment /disk2/home/tk/boost_regression/boost/../regression_comment.html /disk2/home/tk/boost_regression/boost cs-IRIX64.html cs-IRIX64-links.html Could not open Jamfile: /disk2/home/tk/boost_regression/Jamfile **** error return code: 1 ******** errors detected; see standard output for details ******** Failed HTML result table generation.

1 0

Re:[boost] serialization 1.31 compilation error.
by Robert Ramey 07 Jul '04

07 Jul '04

Russell Balest wrote: >Possibly triggered by the using statement: >using namespace boost::serialization; >on line 53 of iserializer.hh , but that's a guess. Using "using" in the header was an error that was pointed out during the formal review. My current copy has fixed this a new version will be available very shortly #20. This will be guaranteed compatible with 1.31. Also very shortly the latest version will be checked into main CVS. So you can wait a little bit or remove the "using from your copy of the iserializer.hpp Robert Ramey

1 0

Interest in strict unit style typing for physics/science calculations
by edA-qa mort-ora-y 07 Jul '04

07 Jul '04

Is there any interest in a library that performs strict type checking on values with unit quantities? The intent is to prevent operation and assigment of unlike types. For example, if A is in meters/second, and B is in seconds: -A * B results in a value with "meters" units -A / B results in a value with "meters/seconds^2" -A = B results in an exception due to a mismatch The code I have so far supports arbitrary unit types via tokens, which have to be defined for a project. Some example code looks like (with several notation options): typedef UnitValue<float> uFloat; UnitType unit_m( 1 ); //define meters type UnitType unit_s( 2 ); //define seconds type uFloat time( unit_s ); time = unit_s( 3.0f ); //3 seconds uFloat speed( unit_m / unit_s ); speed = 15 * speed.Type(); //set speed of 15m/s uFloat accel( unit_m / unit_s / unit_s ); accel = speed / time; //results in 5m/s^2 accel = speed; //throws exception, m/s != m/s^2 time = accel; //throws exception, s != m/s^2 The library has a price for performance compared to native value operations. However, part of the requirements will be a flag (a #define ) that turns off the unit processing for the code, which effectively removes the classes (replaces the UnitValue simply with typedefs of the stored type). -- edA-qa mort-ora-y Idea Architect http://disemia.com/

3 3

Write access to the CVS repository
by Edward Diener 07 Jul '04

07 Jul '04

I wanted to correct a spelling error in one of the Boost CVS documentation files but I didn't have write access to the Boost CVS repository. Is there a way to get this ? If not, should I mention such an error on this NG or is there some other place ?

3 9

RE: [boost] Boost.Test, failed assert output
by Glen Knowles 06 Jul '04

06 Jul '04

> From: Rozental, Gennadiy > I will see what I can do about it. If I remember correctly, > the problem is that I do not know where the error occurred. > So I have no way to print line pointing there. I could print > only line pointing where the error was caught/detected. I am > not sure it is what you want. Ideally you would point to the line, but I can simply look at the output from the assert which has the file/line info. I just want the IDE to notice that there was an error so that I'll know something went wrong. As far as I'm concerned you could make up a file and line if that's what it takes to stop the build, in fact reporting an "unknown location" would probably cause less confusion then reporting the place inside boost.test where the error was detected. Thanks, Glen

1 0

BGL Algorithm (Network Flow)
by Tanton Gibbs 06 Jul '04

06 Jul '04

I'm attempting to do a graph algorithm and am looking for a good BGL algorithm to do this -- any advice would be appreciated. Basically, I have a directed, weighted, bipartite graph. I'll call the two sets of nodes (V,W). Every node in V connects to one or more nodes in W. However, not every node in W is connected to. When the algorithm ends, I want every node in V to be connected to 0 or 1 node in W and no node in W should have more than one connection to it. I also want the total weight of all the edges to be minimized (basically, prune the most costly edges to create the graph), but no edge should be pruned unnecessarily (I want to maximize the number of connected nodes). It looks to me to be a pretty evil problem, but I'm hoping someone has a good suggestion. Thanks! Tanton H. Gibbs, Ph.D. Software Developer Acxiom Corporation

1 0

Re: [ublas-dev] Re: [boost] Re: Boost Mathematicians
by Jeremy Graham Siek 06 Jul '04

06 Jul '04

Hi Michael, On Jul 5, 2004, at 4:52 PM, Michael Stevens wrote: > Hi Jeremy, > > Thanks for chipping in on this. I don't think we have conversed > before, apart > from maybe a few patches I submitted for MTL. Although it would be > great for > everyone to work on uBLAS I think a revived MTL would also be a good > thing. > The design of MTL was very influential. Thanks! > I won't comment on the other issues as I have already posted a few > thoughts on > these matters. > > > > Mmmh, this open pitfalls concerning A*B*C in performance issues > for > > > non experts. > > > > No, the right way to handle this is to have the expression template > > machinery > > identify that a temporary is needed, and create one automatically. > > I wonder if you caught the discussion on this about 6 months ago. I > would > strongly argue that the automatic creation of temporaries in the > subexpression context is a bad thing... > > The roles of the expressions we declare (as in declarative > programming) is > twofold. a) to express the mathematical context b) to express how > this should > be computed. That is, to be able to express how the expression is to > be > evaluated. This gives us control over its numerical properties and > also of > the time and space complexity. > > In principle, uBLAS has a one to one relationship between an > expression and > how it is evaluated. Simply stated this is based on an element by > element > evaluation of assignment. There are shortcuts in the case of sparse > types but > the principle holds. > > An expression A+B+C can be evaluated in this manner trivially. > A*B*C can also be evaluated in this manner, although the element by > element > rule results in an O() that is not what many users expect. > To get the O() that users expect we could automagically insert > temporaries. I > fear this is a tar pit however. What temporary should be chosen? Each > of A B > or C could be a either dense, sparse, compressed, banded, symmetric or > combinations therefore. The type the user expects or is "the best" is > not at > all clear. Although automagically inserting temporaries in non-trivial (especially since it must all be done with template meta-programming) I do not think it is a tar pit. Here is the simply heuristic that I used for MTL 3 to decide where to put temporaries: 1. If an operation needs to read from an argument multiple times, evaluate the argument eagerly into a temporary. For example, a sparse matrix in compressed row format times the sum of two vectors: A * (x + y) In this case, the (x + y) would be evaluated into a temporary before evaluating the multiplication. 2. If an operation writes into its output in multiple passes, then perform the operation in an eager fashion. For example, the sum of a vector and the product of a sparse matrix in compressed column format and a vector. x + (A * y) In this case, the (A * y) would be evaluated into a temporary before evaluating the addition. > > I think the only correct solution is to force the user to specify > this type. > Incidently, the no temporary evaluation should also be an option as > in some > cases (small sizes) it is desirable. uBLAS currently disallows this > to avoid > confusing the user. I should be reinstated in some form however. > > All the best, > Michael > > -- > ___________________________________ > Michael Stevens Systems Engineering > > 34128 Kassel, Germany > Phone/Fax: +49 561 5218038 > > Navigation Systems, Estimation and > Bayesian Filtering > http://bayesclasses.sf.net > ___________________________________ > > _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________

3 2

Re:Re: [boost] Re: 1.32 release preparation
by Robert Ramey 06 Jul '04

06 Jul '04

Johannes Brunen wrote: >> And if there are a large >> number of new things left out by that approach then we should plan >> another release sooner rather than waiting 4 months. >However, then you need new volunteers which have to spend the time for the >whole procedure again. The release procedure is too onerous. This isn't the problem, it's a symptom of a more subtle problem. If the source of this difficulty can be found can corrected, then releases can occur more frequently. My personal view is that it's a symptom of a development process that couples otherwise independent/orthogonal efforts. This is due to the fact that we're all working against a development tree that has experimental code in it. So minor issues ripple across all efforts. >I could think of a review process which accepts a library only after the >list of requested changes has been made. > I would prefere a review process which leads to final > acceptance only after a library is 'CVS' compatible i.e. does not yield to > any (known) regressions of the existing pool libraries and is equipted > with a working testing facility. The review process qualifies submissions for inclusion into boost. I don't think there are any libraries that have been accepted then suffered changes which made them unacceptable. It's not fair to ask a submitter to require that that he totally "finish" the package before submission when it cannot be guaranteed that it will be accepted. The review process isn't the problem, its working quite well. It's just that there is more effort than first meets the eye between the time a library is deemed acceptable and the time it is ready for inclusion into boost. The serialization library including code, headers, tests, html, jamfiles, *.bat, and shell scripts is has passed 25,0000 lines. This takes time and no changes in the review or release procedure can change that. There is the review package which seems to work pretty well. But I would be reluctant to check it in as it doesn't match the review acceptance conditions and I'm concerned about trying to maintain a package which I have now moved beyond. Robert Ramey

3 3

Re: [ublas-dev] Re: [boost] Re: Boost Mathematicians
by Jeremy Graham Siek 06 Jul '04

06 Jul '04

On Jul 5, 2004, at 11:54 AM, Peter Schmitteckert wrote: > Salut, > > (note that I only use the dense matrices of ublas) > > On Mon, 5 Jul 2004, Toon Knapen wrote: > > > > This is just a matter of documentation. AFAIK there is no accepted > > concept that demands 'num_rows' and 'num_columns'. The '1' and '2' > refer > > to the first and second index which is also a nice convention IMO. > > I prefer size1 and size2, since it fits to the sheme of having a > tensor > structure with a size3. Mixing up abstractions is not a good idea. Matrices and tensors are different creatures. True, sometimes it is useful to think of a tensor as a matrix, and having adaptors or views that allow for this is a good thing. The names we use for operations should match the common terminology from the problem domain. In this case, the common terminology is rows and columns. When we create concepts for tensors, we can use size1, etc. > Columns and Rows can lead to confusion concernig storage layout. I disagree. > > > > > > > > * iterator1 and iterator2 should be named column_iterator and > > > row_iterator or something memnonic. > > same as above. > > same as above. > > > > > > > > > * prod should be named operator*; this is a linear algebra library > > > after all. > > Mmmh, this open pitfalls concerning A*B*C in performance issues for > non experts. No, the right way to handle this is to have the expression template machinery identify that a temporary is needed, and create one automatically. Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________

7 12

unresolved externtal symbol with .Net 2003
by Brian Carlson 06 Jul '04

06 Jul '04

I have a project that worked fine with .Net 2002 (7.0.9466). But when I open it up on .Net 2003 (7.1.3088) it compiles, but when it links I get the following warning: CDlgcEventProcessor.obj : error LNK2019: unresolved external symbol "public: __thiscall boost::thread::thread(class boost::function0<void,struct boost::empty_function_policy,struct boost::empty_function_mixin,class std::allocator<class boost::function_base> > const &)" (??0thread@boost@@QAE@ABV?$function0@XUempty_function_policy@boost@@Uemp ty_function_mixin@2@V?$allocator@Vfunction_base@boost@@@std@@@1@@Z) referenced in function "protected: int __thiscall DlgcFW2::CDlgcEventProcessor::StartThread(void)" (?StartThread@CDlgcEventProcessor@DlgcFW2@@IAEHXZ) Anyone have this kind of problem before?

2 1

RE: [boost] Boost.Test, failed assert output
by Rozental, Gennadiy 06 Jul '04

06 Jul '04

I will see what I can do about it. If I remember correctly, the problem is that I do not know where the error occurred. So I have no way to print line pointing there. I could print only line pointing where the error was caught/detected. I am not sure it is what you want. Regards, Gennadiy.

1 0

Question about stdlib in gcc-2.95.3-linux toolset
by Joaquín Mª López Muñoz 06 Jul '04

06 Jul '04

A test of mine is failing in the gcc-2.95.3-linux toolset with the following: ostream: No such file or directory which, I guess, indicates that the std library used by this toolset does not have a <ostream> header. Digging through the regression logs, seems like the library being used is SGI's. Now, there is not defect macro in config/stdlib/sgi.hpp indicating that <ostream> is not available, so my question is: * Is this defect in gcc 2.95 known, and not an installation artifact? * If so, is there any way to figure it out from Boost.Config defect macros or some combination of these and SGI-specific macros? Maybe I'm missing something obvious and this lack of standard headers by gcc 2.95 is common knowledge, I just happen not to have dealt with this compiler ever. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Does anyone have an is_virtual_base_and_derived ?
by Robert Ramey 06 Jul '04

06 Jul '04

Type traits includes: ::boost::is_base_and_derived<T,U> Does anyone have a version that might be called is_virtual_base_and_derived<B, D> which would return true iff D is derived virtually from B ? Robert Ramey

1 0

Re: [utility] boost::reset
by jhopkin＠reflectionsinteractive.com 06 Jul '04

06 Jul '04

Daniel Frey wrote: > > Gennaro Prota wrote: > > > Does the swap trick necessarily free the memory? > > AFAIK, yes. See <http://www.gotw.ca/gotw/054.htm>. > The STL implementation I have been using seems to allocate a buffer on first insertion into any container of a given type, and frees it only when it feels like it (often on program shut-down). I don't know if it's a strictly conforming implementation in that respect, although I can't see anything in the standard prohibiting this behaviour. James Hopkin

3 2

Re: Boost Mathematicians
by Michael Stevens 06 Jul '04

06 Jul '04

On Monday 05 July 2004 22:59, David Abrahams <dave(a)boost-consulting.com> wrote: > > Almost all the major reference works on BLAS and Matrices > > simply state elements are either Real or Complex and are therefore > > implicitly a field. > > We're not just concerned about the elements of matrices, but the > vectors and matrices themselves. OK I was assuming you were looking for a clear concept definition for the element types. > This becomes a real issue when you > have to write algorithms that might operate on matrices of reals or > matrices of matrices -- yes, these things do come up in real > applications. This is very odd. In linear algebra there is no such thing as a matrix of matrices. This impacts on the while prod/operator* controversy. That is, the primary advantage of not defining operator*. It prevents you passing matrix to an algorithm (not necessarily part of the uBLAS itself) that uses operator* and not unreasonably makes the assumption that operator* is commutative. The assumption is not unreasonable as all built in types operator* is exactly commutative. That said I have also argued in favour of operator* instead of prod in the past. It's central role in LA certainly argues in favour of using operator*. This involves so much peoples expectation as for algebraic notation, programming practice and just personal taste. > >> * Redundant specification of element type in matrix/vector storage. > > See my reply to Toon. Ah yes value_type is specified in both the matrix vector and storage type parameter list. In itself this is not good as the storage type should parameterise the matrix/vector with the value_type. It is simply there to make the syntax in the default case simple without the need for a type generator as in MTL. > > For std::slice (valarray) compatibility stride should be last. Not sure why > > this was not picked up on a long time ago!! > > valarray (and uBLAS) use size (not end) for good reason however. > > ...which is...? The begin end definition fails when stride==0. Slices of finite size with stride==0 are very useful. Similarly when (end-begin) *stride <0 the behaviour would have to be defined. > > Interesting solution. Agreed, the current implementation is closed to other > > objects because of the intrusive base class. Sadly uBLAS was designed before > > enable_if. Any pointers to compile/runtime effects of the enable_if solution? > > I can't really imagine what you're asking for here. I was looking for any publications/links to compare how compilers do between the two solutions. Anyone have any pointers? Thanks, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

4 5

[utility] boost::reset
by Daniel Frey 06 Jul '04

06 Jul '04

Hi, I just wrote a small helper function to clear a container. Well, OK, we already have that, do we? For a container 'cont': cont.clear(); But this doesn't neccessarily free the memory allocated. The "usual" workaround is: Cont().swap( cont ); But Cont (the type of the container) is sometimes rather large and the code doesn't communicate well what I intended. I thus wrote the following small helper: template< typename T > void reset( T& t ) { T().swap( t ); } Would this make a good addition to boost.utility? Any comments welcome... Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey(a)aixigo.de, web: http://www.aixigo.de

5 13

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 06 Jul '04

06 Jul '04

> From: Howard Hinnant > > Exploring the case: throw exception if unable to atomically > promote read to write: > > If an exception is not thrown, then you are guaranteed what > you previously read is still true, and all is well. If an > exception is thrown, then you have to re-read to determine > current state. First, to be clear, a promote() _must_ not be allowed to silently fail, otherwise you break the contract and people will spend several days tracking down the problem. If you want that behavior you should use try_promote(). I don't have a problem with it simply deadlocking, or, if that's unacceptable don't have the blocking promote() function. The complexity involved in determining a deadlock may be well beyond what you want to do at this level in the library, I'll come back to this later. But for now, lets talk about throwing. In my mind the purpose of throwing is to allow the other thread (or threads, with the database work I've been doing multiple read locks on an object all trying to be promoted to write locks at the same time happens more often then you might think) to proceed, which it can't do unless you give up your _read_ lock. > > Hmm... > > Given that when you have write privilege you also implicitly > have read privilege, this seems a little extreme. Would it > not be both more efficient and easier to follow if you just > reaffirm your state under the write lock rather than assume > your state, and write a catch block to reassert it if it > happens to be false? That is, this: > > bool try_sale(rw_mutex& m) > { > read_lock rl(m); > > long balance = get_balance(); > long cost = get_total_cost(); > > if (balance > cost) > { > write_lock wl(rl); > set_balance(balance - cost); > // ... > return true; > } > return false > } > > bool do_sale(rw_mutex& m) > { > while (true) > { > try_again: > try { > return try_sale(m); > catch (rw_promotion_error&) { > // Try the whole thing again > // how is this implemented? > goto try_again; // ? > } > } > } > > vs this: > > void do_sale(rw_mutex& m) > { > read_lock rl(m); > > long balance = get_balance(); > long cost = get_total_cost(); > > if (balance > cost) > { > rl.unlock(m); > write_lock wl(m); > set_balance(balance - cost); > wl.transfer_to_read_lock(rl); > balance = get_balance(); > } > // ... > } > > My assertion is that you don't know a-priori if the > read-to-write promotion achieves anything or not. If you > allow it to fail, by exception, or by error code, or by any > other means, then you have to write code to re-read the > current state. If you don't allow it to fail, then you must > make it block until it succeeds. The latter seems simpler in > logic, and smaller in code size. The logic is quite simple: > > read_lock to write_lock promotion is not atomic. > > Once that is understood, the programmer can just deal with > it. Trying to encapsulate this bit of reality only serves to > obfuscate the necessary logic. The reason that "release read, acquire write" appears a complete alternative to promotion is because your example is too simple. You may need the read lock to keep the object alive in a cache, where it could be flushed to disk and destroyed if you release it, forcing you to re-read it before getting your write lock. I think that the library should either commit to detecting deadlocks or don't do it at all. Is it going to throw a promotion exception in this case? Thread A: read lock x Thread A: read lock y Thread B: read lock y Thread B: write lock x, blocks Thread A: promote y to write lock, blocks In order to detect things like this you essentially need to build a complete conflict matrix of all held locks in the system, and if you do that I assume you'd also use it to detect deadlocks of regular locks: Thread A: lock x Thread B: lock y Thread A: lock y, blocks Thread B: lock x, blocks Glen

2 1

Re: Boost Mathematicians
by Michael Stevens 06 Jul '04

06 Jul '04

On Tuesday 06 July 2004 01:30, "Aleksey Gurtovoy" <agurtovoy(a)meta-comm.com> wrote: > Neither 'size1' nor 'num_rows' are generic, though. What you want is > something like > > template< int n > size(int_<n>); > > The particular int_<n> specializations then can be typedef'ed to > something more mnemonic, e.g. > > typedef int_<0> rows; > > or even > > extern int_<0> rows; > > The lack of this genericity will force you, sooner or later, to resort > to code duplication. I believe Vesa made the same point a long time > ago... yep: http://thread.gmane.org/gmane.comp.lib.boost.devel/60338. Aleksey, Thanks for point this out. I had forgotten about Vesa contribution. It seems this is very much a repeat of the discussion you link to. Interestingly uBLAS never did get the generic versions of the functions. Although it gained a set of similar functions for major/minor mappings. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

Re: Lightweight Mutex Code
by Tyson Whitehead 06 Jul '04

06 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron W. LaFramboise wrote: > I am not sure what the status of these are. Are other components > supposed to be using these? I came upon them when I was checking out the smart pointers implementation. Grepping the source seems to indicate 'lightweight_mutex.hpp' is only used by the smart pointers (only included by 'quick_allocator.hpp' and 'shared_count.hpp') under multithreaded conditions. > In addition to what you mentioned, they're broken in other ways: > > If a low priority thread is preempted by a high priority thread > immediately before __atomic_add, and the high priority thread is > attempting to grab the spinlock, deadlock is acheived, despite the > sched_yield(). I missed that one. You're right though, and not only that, but the sched_yield manpage states (I'm assuming this applies to threads -- threads in Linux are actually processes -- right?): "Note: If the current process is the only process in the highest priority list at that time, this process will continue to run after a call to sched_yield." The implementer seemed to be aware there could be priority problems though. The relevant comments in 'lightweight_mutex.hpp' are: // * Used by the smart pointer library // * Performance oriented // * Header-only implementation // * Small memory footprint // * Not a general purpose mutex, use boost::mutex, CRITICAL_SECTION or // pthread_mutex instead. // * Never spin in a tight lock/do-something/unlock loop, since // lightweight_mutex does not guarantee fairness. // * Never keep a lightweight_mutex locked for long periods. // // The current implementation can use a pthread_mutex, a CRITICAL_SECTION, // or a platform-specific spinlock. // // You can force a particular implementation by defining // BOOST_LWM_USE_PTHREADS, // BOOST_LWM_USE_CRITICAL_SECTION, or // BOOST_LWM_USE_SPINLOCK. // // If neither macro has been defined, the default is to use a spinlock on // Win32, and a pthread_mutex otherwise. // // Note that a spinlock is not a general synchronization primitive. In // particular, it is not guaranteed to be a memory barrier, and it is // possible to "livelock" if a lower-priority thread has acquired the // spinlock but a higher-priority thread is spinning trying to acquire the // same lock. // // For these reasons, spinlocks have been disabled by default except on // Windows, where a spinlock can be several orders of magnitude faster than a // CRITICAL_SECTION. The current Win32 doesn't have the counter problems, and claims to be able to yield to lower priority threads, so it should be okay. The relevant lock routine is (m_.l_ is initialized to 0): while( InterlockedExchange(&m_.l_, 1) ){ // Note: changed to Sleep(1) from Sleep(0). // According to MSDN, Sleep(0) will never yield // to a lower-priority thread, whereas Sleep(1) // will. Performance seems not to be affected. Sleep(1); } The unlock routine is: InterlockedExchange(&m_.l_, 0); - -T - -- Tyson Whitehead (-twhitehe(a)uwo.ca -- WSC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6a+FRXbLmIoqtdgRAqxRAJ0RxqXlsbc5i5GBCydxFWgqTU32sQCgyJ/Y py3rSxTj5BiVUmXPqoP/zcY= =nVLD -----END PGP SIGNATURE-----

5 8

Lightweight Mutex Code
by Tyson Whitehead 06 Jul '04

06 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I believe there is a mistake in the 'details/lwm_gcc.hpp' and 'details/lwm_linux.hpp' (and possibly the other lightweight_mutex implementation as well -- I haven't looked at them). In both of these files we have a counter (m_.a_) that is initialized to 1. The lock routine is implemented as follows: while( !__exchange_and_add(&m_.a_, -1) ){ __atomic_add(&m_.a_, 1); sched_yield(); } The unlock as: __atomic_add(&m_.a_, 1); This works if there are only two contenders for the lock. It can fail if there are three or more: 1- Thread one takes the lock, putting the counter at 0. 2- Thread two does the __exchange_and_add, fails the test, and then its time time slice expires before the __atomic_add, leaving the counter at -1. 3- Thread three also takes the lock (because !-1 is false). A simple solution is to initialize the counter to zero and replace the above lock by: while( __exchange_and_add(&m_.a_, 1) ){ __atomic_add(&m_.a_, -1); sched_yield(); } and the unlock by: __atomic_add(&m_.a_, -1); This would result in: 1- Thread one takes the lock, putting the counter at 1. 2- Thread two does the __exchange_and_add, fails the test, and then its time slice expires before it can do the __atomic_add, leaving the counter at 2. 3- Thread cannot take the the lock (because 2 is true). - -T - -- Tyson Whitehead (-twhitehe(a)uwo.ca -- WSC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5dgwRXbLmIoqtdgRAmbyAJ0aZFZvxn5MXeXyNqSAI63o9EqddQCfTK9p wFAoBbQueoo9hLNhXJtit44= =SPra -----END PGP SIGNATURE-----

3 2

Re:Re: [boost] Re: 1.32 release preparation
by Robert Ramey 06 Jul '04

06 Jul '04

Message: 16 Date: Sun, 27 Jun 2004 22:25:47 -0500 From: "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> Subject: Re: [boost] Re: 1.32 release preparation To: boost(a)lists.boost.org Message-ID: <40DF8FBB.4040408(a)aaronwl.com> Content-Type: text/plain; charset=us-ascii Aaron W. LaFramboise wrote: >Robert Ramey wrote: >> Dave Abrahams wrote: >> >> >>>I'd like to know the reasons for "all the sudden rush". We did >>>announce a schedule long ago, and it has already been delayed by three >>>weeks. I'm not asking in order to point fingers; I just want to know >>>how to avoid the "sudden rush" next time. >> >> >> Here is the current scenario. >> >> a) The announcement gets posted - release 1.32 scheduled for date x. >> b) Each developer decides - uh oh I better get in my changes before date x. >> c) Of course these changes take longer >> d) and break some other things >> e) which takes longer still >> >> Personally I think the concept of scheduling a release fundamentally flawed. >> I would suggest another idea. >As an observer, I'm fairly impressed with GCC's release methodology. >http://gcc.gnu.org/develop.html >A critical component is a schedule that includes several stages during >which certain sorts of changes are unacceptable. >There's still rush, but most of the rush for major features or other >destabilizing elements happens long before the release comes around. I found this to be very interesting. I had never seen this before. It basically implements my view that the "Main Line" should be code that is always works and is ready to be used, tested and potentially released. As far as I'm concerned it's totally consistent with my proposal which I thought was un-orthodox but now see that is used at least by GCC. So, my view would be - stick to the original 28 June date, require that new libraries be added to branches and merge to main as appropriate. I realize its not THAT easy - but it would address the concerns that I have about the whole process and allow all libraries to proceed on independent schedules. New libraries would be tested against the "known good tree" independently of one another. Take as a small example changes in MPL. The current method is to check in a new version of MPL and see what happens. Presumable some issues will arise and now we have a broken system which inhibits development of other libraries until the issues are resolved. Under the proposed method, the new MPL would be check in under its own branch and issues would be detected on all libraries before they affect other developers. Anyway - my 2 cents. Robert Ramey

8 16

boot::mpl::list problem
by zaufi 06 Jul '04

06 Jul '04

Hi all! I have a problem compiling the following simple program without defining BOOST_MPL_NO_PREPROCESSED_HEADERS. Though obviously there are preprocessed headers in boost/mpl/list/aux_/preprocessed/plain. The problem seems to be in compiler-specific preprocessed header (for example boost/mpl/aux_/preprocessed/gcc/list.hpp) where list is defined with 10 arguments regardless of BOOST_MPL_LIMIT_LIST_SIZE value. ---{boost_list.cc} --------------------------------------------- // # define BOOST_MPL_NO_PREPROCESSED_HEADERS # if !defined(BOOST_MPL_LIMIT_LIST_SIZE) || (BOOST_MPL_LIMIT_LIST_SIZE < 20) # undef BOOST_MPL_LIMIT_LIST_SIZE # define BOOST_MPL_LIMIT_LIST_SIZE 20 # endif #include <boost/mpl/list.hpp> typedef boost::mpl::list< int, int, int, int, int , int, int, int, int, int , int, int, int, int, int > my_list; int main() { my_list l; return 0; }; ---------------------------------------{end of boost_list.cc}--- any suggestions?? regards. zaufi.

2 1

Boost.Test, failed assert output
by Glen Knowles 06 Jul '04

06 Jul '04

This is my first time using Boost.Test. I was able to get started pretty quickly from the docs, and I'd like to start by saying that the library looks pretty good. Now for my request. ;) I'm using vc++ 7.1, and when an assert unexpectedly fails I'd like the framework to output a message that is recognizable by the IDE as an error. What I'm seeing right now is: ------ Build started: Project: CBdbRangeSummary_test, Configuration: Debug Win32 ------ Run unit tests Assertion failed: 0, file .\CBdbRangeSummary.cpp, line 33 Running 3 test cases... Exception in "single_rnode_test": This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Build Time 0:00 CBdbRangeSummary_test - 0 error(s), 0 warning(s) ---------------------- Done ---------------------- Build: 1 succeeded, 0 failed, 0 skipped Thanks, Glen Knowles Centor Software Corporation

1 0

Re: [ublas-dev] Re: Boost Mathematicians
by Jeremy Graham Siek 06 Jul '04

06 Jul '04

Hi Paul, I agree with you. The use of operator* does not imply commutativity. Cheers, Jeremy On Jul 5, 2004, at 6:04 PM, Paul C. Leopardi wrote: > Hi all, > Reply to a sub-issue below. > Best regards > > On Tuesday 06 July 2004 02:58, Peter Schmitteckert wrote: > > This imples, that the elements of a matrix need not be commutative, > > having again consequences for general routines using operator*(), > > since this oftemn implies the commutativity of elements. > > Can anyone explain to me why operator* implies the commutativity of > elements? > The GluCat library ( http://glucat.sf.net ) uses operator* and its > elements > do not necessarily commute under multiplication. > > How would you use expression templates to implement a non-commutative > group > concept, or more to the point, a ring or an algebra? My first thought > for > this was to use operator* as it seems most natural, and in the case of > Clifford algebras, gives subalgebras isomorphic to the quaternions, > complex > numbers and real numbers. > > Of course, this discussion comes from a mathematical viewpoint rather > than a > computer science viewpoint, but I don't see why these viewpoints need > be > incompatible. > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > <lrec_companion_043004.gif> > <l.gif> > > Yahoo! Groups Links > > • To visit your group on the web, go to: > http://groups.yahoo.com/group/ublas-dev/ > > • To unsubscribe from this group, send an email to: > ublas-dev-unsubscribe(a)yahoogroups.com > > • Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________

1 0

Re: [boost] Random number library
by Kris Thielemans 06 Jul '04

06 Jul '04

Hi 3 more comments on the random number library. 1) Further on the topic started by Oliver Kullmann, and the reply by Cromwell Enage: -------Start Quote:--------- typedef boost::uniform_int<> UniformDist; UniformDist dist(min,max); typedef boost::mt19937 BaseRNG; BaseRNG rng; boost::variate_generator<BaseRNG&,UniformDist> your_generator(rng, dist); Note the ampersand; your program will fail silently if you omit it. -------End Quote:--------- An example why you could need the &: Suppose you have your_generator being defined locally, as it depends on some run-time parameters int f(int min, int max) { UniformDist dist(min,max); static BaseRNG rng; boost::variate_generator<BaseRNG&,UniformDist> your_generator(rng, dist); return your_generator(); } If you don't have the &, the variate_generator constructor will make a fresh copy of the rng object every time f() is called. Result: your random number will always be the same! On the other hand, using it without ampersand works fine for me in other situations. I find this rather subtle (i.e. it took me a few hours to understand why my data were not what they should have been). So, maybe the documentation for variate_generator should be more explicit about this. I've tried to write a doc for this, but find that it probably needs explicit examples. Here it is anyway "Whether you use a reference, pointer, or 'plain' type for the Engine template parameter of variate_generator<Engine, Distribution> depends on similar considerations as for ordinary functions. E.g. if a reference is used, subsequent calls of the variate_generator::operator() will modify the state of the referenced Engine object, which is probably useful if the same Engine object is used for multiple variate_generator<Engine, Distribution> objects. " -------------------------------------------------- 2) While on the topic of references, the following generates a compiler error. boost::uniform_01<BaseRNG &> random01(generator) /home/kris/mydoc/include/boost/random/uniform_01.hpp:58: error: forming reference to reference type `stir::base_generator_type&' -------------------------------------------------- 3) on distribution::operator()(Engine& eng) template<class Engine> normal_distribution::operator()(Engine& eng) assumes that Engine is like uniform_01. This not documented, and worse, also not checked in the code. template<class Engine> result_type operator()(Engine& eng) { if(!_valid) { _r1 = eng(); _r2 = eng(); _cached_rho = sqrt(-result_type(2) * log(result_type(1)-_r2)); _valid = true; } else { _valid = false; } // etc I would recommend to insert something like assert(eng.min()==result_type(0)); assert(eng.max()==result_type(1)); BOOST_STATIC_ASSERT(!std::numeric_limits<Engine::result_type>::is_intege r); Of course, when using variate_generator<Engine, normal_distribution<double> > the Engine is converted into a uniform_01 if necessary. I'm afraid that the same is true for the gamma_distribution and geometric_distribution class. So, maybe some_distribution::operator()(Engine& eng) should not be used at all. If so, it should not be public (at least for compilers that can do template friends I guess). However, it is required by the 'Random Distribution' concept. Any particular reason that we need it? Kris Thielemans Hammersmith Imanet Du Cane Road London W12 0NN UK http://www.HammersmithImanet.com/~kris

1 0

Attn: Eric Niebler - Xpressive
by Dan 05 Jul '04

05 Jul '04

I downloaded the xpressive files and had a look through the files. I'm interested. I'd like to put xpressive to work in a real parsing application (it's the early stages of development so I'm confident we will work through any issues well before release). I've been getting a vague idea of how things work through the tests, and I may find more in the source files, but what I really need is a quick explanation of the basics. If you haven't already, I'd seriously recommend writing a quick start guide and placing it with the project files. If you have some documentation, I'd love to get access to that but otherwise just a brief explanation of the basics will suffice for now. It is my hopes that xpressive will make development and maintenance of our application easier and that our use of the library will help shape xpressive's development in a positive fashion. -Dan

2 1

Administrative Requests
by David Abrahams 05 Jul '04

05 Jul '04

Just a reminder -- I'm not the only moderator. Please post all administrative requests to boost-owner(a)lists.boost.org so that the workload of responding to them is distributed across everyone who can handle them. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 2

Re: Boost Mathematicians
by Michael Stevens 05 Jul '04

05 Jul '04

On Saturday 03 July 2004 16:54,David Abrahams <dave(a)boost-consulting.com> > Jeremy and I have just completed a re-evaluation of uBlas based on > what's in uBlas' own CVS repository, having not discovered that until > recently (you should have that info on uBlas' Boost page!) We have > some major complaints with uBlas' design. The list is long, and the > issues run deep enough that we don't believe that uBlas is a suitable > foundation for the work we want to do. This is very interesting. Thanks for writing this up and posting. I can't address all the issues. However those which I can I will endeavor to give you and the Boost community my feedback on. First of all I am currently making sure Boost is updated with the latest uBLAS development version. This already has updated documentation which points to all the correct locations for discussions, CVS and Wiki. This should make it much easier for users to find the correct locations if the stable version in Boost does not meet their needs. To facilitate the development of solutions I will place many of the points into the uBLAS bug tracker on SF. > Interface Design > ---------------- > > * Not grounded in Generic Programming. The concept taxonomies, to the > extent they exist, are weak, and poorly/incorrectly documented. > Aspects of the design that should be generic are not (e.g. only > certain storage containers are supported, rather than supplying > storage concept requirements). No linear algebra concepts (vector > space, field, etc.) The library is so out-of-conformance with our > expectations for Generic Programming that this one item by itself > is probably enough to make it unsuitable for us. This is a big issue. I believe we need to split the documentation issues from the design issues. Documentation is high on the priority list of many uBLAS users and developers. Most new users start with a requirement for a C++ matrix and BLAS library with nice syntax, efficiency and documentation! The need for clearly defined and documented concepts comes for most people a little latter when extensibility becomes an issue. The storage concept is not as bad as it appears. The concept although not documented is sufficiently well defined that creating a new model is unproblematic. At present the concepts are documented by their models :-) > No linear algebra concepts (vector space, field, etc.) I not sure if these concepts really need to be defined. They are already well described in many mathematical text books and in Wikipedia. Almost all the major reference works on BLAS and Matrices simply state elements are either Real or Complex and are therefore implicitly a field. Of course a C++ linear algebra library should be generic enough to work with any type which is a numeric approximation to a field. > > * Redundant specification of element type in matrix/vector storage. Not sure what is meant here, can you elaborate ? > * size1 and size2 should be named num_rows and num_columns or > something memnonic > > * iterator1 and iterator2 should be named column_iterator and > row_iterator or something memnonic. I think many uBLAS users have come to appreciate the brevity of naming. I think the concensus in the Boost review was as long as they were used consistenty these names are acceptable. > * prod should be named operator*; this is a linear algebra library > after all. Oh, there has been much ink spent on this! Joerg argues against operator* for two reasons I think. a) operator* brings an expectation of commutativity and this is not the case in linear algebra b) The are many products (inner,outer,element) and there should be a clarity of naming. > * begin() and end() should never violate O(1) complexity expectations. > > * insert(i,x) and erase(i) names used inconsistently with standard library. Agreed. > * Matrix/Vector concept/class interfaces are way too "fat" and need to > be minimized (e.g. rbegin/rend *member* functions should be > eliminated). Interesting. Certainly the fatness is a worry. I think rbegin/rend need to stay as members as this is part of the Reversible Container concept. > * The slice interface is wrong; stride should come last and be > optional; 2nd argument should be end and not size; then a separate > range interface could be eliminated. For std::slice (valarray) compatibility stride should be last. Not sure why this was not picked up on a long time ago!! valarray (and uBLAS) use size (not end) for good reason however. I also think it would be a mistake to drop range. slices can be degenerate (zero stride) and this has a runtime cost which range does not need to share. > * No support for unorderd sparse formats -- it can't be made to fit > into the uBlas framework. Interesting. I guess this requires some thinking time for a sensible discussion. > Implementation > -------------- > > * Expressions that require temporaries are not supported by uBLAS > under release mode. They are supported under debug mode. For > example, the following program compiles under debug mode, but not > under release mode. > > std::cout << prod (prod(v, m), m) << std::endl; > } > > The workaround to make it compile under release mode is to > explicitly insert the creation of a temporary: > > std::cout << prod (vector<double>(prod(v, m)), m) << std::endl; > > There should be no such surprises when moving from debug to > release. Debug mode should use expression templates, too, as the > differences can cause other surprises. This was changed by Joerg after the last stable release to Boost. I will check there has been no regression. The fix propagates an expression complexity that is statically checked. This check explictly prevents the creation of nested products!! Therefore the correct code is now that with the explicit temporary or with one of the parameterized prod's. The change is aimed at the user. They must clearly express the evaluation and storage complexity of the expressions. The change of semantics between debug/release builds is unfortunate. The partial disabling of the expression templates in debug mode is currently the default and a config macro. With current compiler technology this prevents debuggers crashing and users scrolling through type names that are pages long. In a perfect environment the default would be the opposite. > * Should use iterator_adaptor. There is a ton of boilerplate iterator > code in the uBLAS that needs to be deleted. Agreed 100%. A well used iterator_adaptor would shorten uBLAS definitions to about 30% of their current size !! > * Should use enable_if instead of CRTP to implement operators. uBLAS > avoids the ambiguity problem by only using operator* for > vector-scalar, matrix-scalar ops, but that's only a partial > solution. Its expressions can't interact with objects from other > libraries (e.g. multi-array) because they require the intrusive CRTP > base class. Interesting solution. Agreed, the current implementation is closed to other objects because of the intrusive base class. Sadly uBLAS was designed before enable_if. Any pointers to compile/runtime effects of the enable_if solution? We would however lose the static type checking that argument matching with the CRTP base class gives us. At this point I think we land in a deep philosophical argument as to the strengths and weaknesses of generic progreamming %-) > * Certain operations, especially on sparse matrices and vectors, and > when dealing with matrix_row and matrix_column proxies have the > wrong complexity. Functions such as begin() and end() are suppose > to be constant time. I see calls to find1 and find2, which look like > expensive functions (they each contain a loop). Agreed. The implementation with findN is simple but expensive. I am not sure why Joerg choose this route. > Testing > ------- > * There should be a readme describing the organization of the tests. > > * Tests should not print stuff that must be manually inspected for > correctness. > > * Test programs should instead either complete successfully > (with exit code 0) or not (and print why it failed). Agreed. If anyone submits a patch it would be included very quickly! > * Abstraction penalty tests need to compare the library with tuned > fortran BLAS and ATLAS, not naive 'C' implementation. There was some very good work on this about a year ago. Sadly the results are no longer accessable on the web. Since the loss to Intel of the KAI compiler it is hard to see any library archiving really exceptional results in this regard. > Documentation > ------------- > > * In really bad shape. Redundant boilerplate tables make the head > spin rather than providing useful information. > > * Needs to be user-centered, not implementation centered. > > * Need a good set of tutorials. Agreed. > Compilers > --------- > > * Simple example doesn't compile with gcc 3.3. Got it to compile by > #if'ing out operator value_type() in vector_expression.hpp. Strange gcc-3.3.3 is my primary compiler. Can you specify the problem more exactly. Which gcc-3.3 subversion is causing the problem? Thanks, Michael ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

3 4

Re: Boost Mathematicians
by Michael Stevens 05 Jul '04

05 Jul '04

Oppps I forgot the last section of David's posting. On Saturday 03 July 2004 16:54,David Abrahams <dave(a)boost-consulting.com> > > Other then the many forms of blocking (other then banded) uBLAS supports all > > these in its design. > I believe that a design with really good support for blocking can't be > easily grafted onto an existing design that doesn't have it. Now I understand. Blocking in the context of evaluation rather then sparsity/ shape. Yes this is a good point. Blocking evaluation requires significant contribution from the Expression Template mechanism that is not present in uBLAS. > > Other then the lack of ET in the current MTL the big difference > > between the two libraries is the definition of iterators. Neither > > design seems to be perfect with regard to efficiency. > > No, and I have some ideas for addressing that. A improved iterator concept that allows succinct coding and runtime efficiency would be a big step forward. > > > Since uBLAS is already in Boost and has a well established and clean user > > syntax it would seem strange to ignore it. > > Yeah, I stopped ignoring it long enough to determine for sure that we > should probably ignore it :(. No sure what to say here! > > > For the perspective of building further Linear Algebra algorithms it > > would not be too hard to use the syntax sufficiently portably so > > that a future MTL with expression templates could not be used > > interchangeably. > > We have some problems with the syntax too, as you can see from the > above. That said, if the design of MTL makes sparing use of members > and instead relies on free functions, you should be able to make > uBlas syntax adapters ;-) Can't fault the logic here :-) All the best, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 05 Jul '04

05 Jul '04

According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition) template <typename ScopedLock> bool timed_wait(ScopedLock& lock, const xtime& XT); Looking at the code it does appear to require timed_lock either: template <typename L> bool timed_wait(L& lock, const xtime& xt) { if (!lock) throw lock_error(); return do_timed_wait(lock.m_mutex, xt); } What am I missing? BTW. How can I get to have look at the development branch? I went to http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: >>Well, as you point out, try_lock is like a timed_lock with >>time = 0, and lock is like a timed_lock with time = infinity, >>so why not give timed_lock both lock() and try_lock() >>methods as shorthand notation for lock(m, t=0) and >>lock(m, t=infinity)? > > > [Batov, Vladimir] Because, in my view, it violates the fundamental (and > I think widely accepted) OO design principle (guideline?) that in simple > terms can be expressed as "one class, one responsibility". Names like > Bertrand Meyer, Herb Sutter and many others immediately come to mind. > > We can either achieve that by having a universal lock (with timed_lock > as the basis) and shorthand notations in separate derived classes (lock, > timed_lock and try_lock) or by keeping those three completely unrelated > (probably at the expense of some code/functionality duplication). I am > personally leaning towards latter, as even though technically all three > concepts are related, from the user point of view they are distinct. > > >>The argument for try_lock not having a blocking lock() method, >>which you seem to stress more often, is much clearer; I'm much >>more inclined to agree with you there. > > > [Batov, Vladimir] Thank you. I feel that it is important that every > class does what it promises to do. No more, no less. For what it's worth, heres a use case I just ran across illustrating why timed_lock should have a blocking lock() method and/or a blocking locked constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

codewarrior 8.0 problem
by Pavol Droba 04 Jul '04

04 Jul '04

Hi, Regression tests show that codewarrior 8.0 have some problems with string algo lib. Report is here: http://tinyurl.com/35asy It seems, that compiler cannot find std::locale class. Can somebody with an access to this compiler help here. Thanks in advance. Regards, Pavol

6 7

Proposal: Addition to boost::integer_traits
by Jeffrey C. Jacobs 04 Jul '04

04 Jul '04

A while ago I proposed adding a signed_traits class and then after receiving some input decided it better this be a property of some existing traits object, ideally "integer_traits" since only integer can be signed. I tried to contact some people to whom I'd been referred about changing integer_traits.hpp but never heard back. Otherwise I have received no negative feedback from this proposal. The idea is simple, as with the min and max constants associated with boost::integer_traits, there would be: boost::integer_traits<x>::unsigned_type boost::integer_traits<x>::signed_type I also proposed a boost::integer_traits<x>::type But that would be x and so wouldn't be very useful. With these additions, one would be able to get the signed or unsigned form of a type without knowing the type detail. In other words, one can apply "signed" or "unsigned" to any specialized integral type that supports it. (Obviously bool would not be supported, nor would any non-integral types.) OTOH, a user-defined pseudo-integral type could provide its own specialization which would be a way of converting between signed and unsigned Abstract Integral Types (AITs) in a generic way: template <> class integer_traits<my_signed_type> : public std::numeric_limits<my_signed_type>, public detail::signed_integer_traits_base<my_signed_type, my_unsigned_type> { BOOST_STATIC_CONSTANT(bool, is_integral = true); }; Note: here I do not use the boost::detail::integer_traits_base helper because my_signed_type does not have a min or max value and even if it did, it is not possible to do in-class initialization with abstract data types. I would also be providing a specialization of std::numeric_limits. Note also because of these orthagonal properties, I provide a separate base class for signed_integer_traits_base, rather than adding to integer_traits_base. The idea would then be to have a new type in the boost::details namespace: template <class ST, class UT> class signed_integer_traits_base { public: typedef ST signed_type; typedef UT unsigned_type; }; And define each integral type correspondingly, e.g.: template<> class integer_traits<bool> : public std::numeric_limits<bool>, public detail::integer_traits_base<bool, false, true>, public detail::signed_integer_traits_base<bool, bool> { }; template<> class integer_traits<char> : public std::numeric_limits<char>, public detail::integer_traits_base<char, CHAR_MIN, CHAR_MAX>, public detail::signed_integer_traits_base<signed char, unsigned char> { }; // ... template<> class integer_traits<int> : public std::numeric_limits<int>, public detail::integer_traits_base<int, INT_MIN, INT_MAX>, public detail::signed_integer_traits_base<signed int, unsigned int> { }; template<> class integer_traits<unsigned int> : public std::numeric_limits<unsigned int>, public detail::integer_traits_base<unsigned int, 0, UINT_MAX>, public detail::signed_integer_traits_base<signed int, unsigned int> { }; // ... The one problem with this as I see is cv-qualification. Clearly, this will only provide the cv-unqualified types input as if I read ISOC++ 14.1.5 correctly, and I may not be, the top-level cv-qualification of the integral type template parameter would be dropped. E.g.: boost::integer_traits<const int>::signed_type would be [signed] int, NOT const [signed] int. In general, this is what you want because it saves you from writing specialization for each cv-qualification, but it then looses information about the source type, namely how it was cv-qualified. For the other traits, where static functions or constants are provided, the cv-qualification does not matter; it is only in the manifestation of the typedef that causes this inconvenience. However, I think this approach better than none though suggestions and corrections are welcome. Jeffrey.

3 3

[OT] Whether and how to obfuscate email addresses in posts, docs & code
by Andreas Huber 03 Jul '04

03 Jul '04

Dear Boosters What follows is OT, but since this post discusses a problem that I expect to hit boost contributors especially hard I think it is ok to post it here. If not, please let me know. **** lengthy obfuscation rationale begin **** Spammers routinely harvest email addresses from web pages and newsgroups. Viruses scan harddisks to find email addresses of potential new victims. Spammers have even started to use special viruses to install backdoors on computers and then later hijack the infected machines to send their junk to the email addresses found on the harddisk (see e.g. http://tinyurl.com/35usd) Boost contributors are especially vulnerable as their email address is published on the boost website and on the boost list. Moreover, their email address can be found on the harddisks of the thousands of people who use the boost distribution. Despite these vulnerabilities, very few obfuscate their address on the list and in the 1.31 distribution (I don't do so yet, either). Sure, virus scanners and spam filters alleviate the problem but they can never fully solve it. Spammers have become very sophisticated in making their junk pass filters. Although I'm employing multiple spam/virus filters (spamcop, gmx, yahoo) I'm currently getting about 10 unsolicited messages per day (up from about 3 per day a year ago) and I'm concerned what will happen once my address is stored on thousands of hard drives when/if my library is accepted into boost. Sure, I could simply disable my throw-away address and publish a new one as soon as spam/virus levels become unbearable but that also immediately cuts off users who have downloaded the distribution. Plus, this solves the problem only temporarily. So, the only real solution to considerably reduce email junk is to thwart automatic harvest and thus to obfuscate email addresses. I realize that even this offers no guarantee for not receiving spam/viruses as someone sending me email will often have my unobfuscated email address on his/her hard drive but it definitely reduces the number of locations where my address can be harvested considerably. **** lengthy obfuscation rationale end **** Questions: 1. How do other contributors deal with spam/viruses clogging up their in-boxes? Am I worrying about something that will never be a big deal? 2. What do other people think about a voluntary boost standard for obfuscating email addresses published in posts, docs & code? 3. If you think 2. is a good idea then what is a good way to obfuscate email addresses? Is the simple <at> & <dot> approach sufficient or do we need something that is less common (and thus prone to automation)? E.g. WHATah2003EVER(a)gmx.net with a remark to remove all capital letters? Regards, Andreas

4 7

boost/config/suffix.hpp: spurious BOOST_HAS_THREADS with g++ 3.4
by Christoph Ludwig 03 Jul '04

03 Jul '04

While testing gcc 3.4 (on a x86 PC running Linux), I encountered linker errors due to missing pthread symbols, even though my program is single threaded. I found that some translation units using boost::shared_ptr included boost/detail/lwm_nop.hpp whereas other translation units included boost/detail/lwm_pthreads.hpp. I didn't observe any errors with gcc 3.3.x. The problem turns out to be that gcc 3.4 defines the preprocessor variable _REENTRANT if certain standard library headers are included even if the compiler is *not* called with the '-pthread' command line option. The following test exhibits this behavior and shows that it causes BOOST_HAS_THREADS to be erroneously defined in boost/config/suffix.hpp if, e.g., the standard header string is included: cludwig@lap200:~/C++/gcc3.4/tmp> g++ -v Lese Spezifikationen von /opt/gcc/gcc-3.4.0/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Konfiguriert mit: ../gcc-3.4.0/configure --prefix=/opt/gcc/gcc-3.4.0 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-concept-checks --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread-Modell: posix gcc-Version 3.4.0 cludwig@lap200:~/C++/gcc3.4/tmp> cat test-BOOST_HAS_THREADS.cc #if defined(WITH_STRING_HEADER) # include <string> #endif #include <boost/config.hpp> #if defined(__MT__) # warning "__MT__ defined" #endif #if defined(_MT) # warning "_MT defined" #endif #if defined(_REENTRANT) # warning "_REENTRANT defined" #endif #if defined(_PTHREADS) # warning "_PTHREADS defined" #endif #if defined(BOOST_HAS_THREADS) # warning "BOOST_HAS_THREADS defined" #endif cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ test-BOOST_HAS_THREADS.cc cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ -DWITH_STRING_HEADER test-BOOST_HAS_THREADS.cc test-BOOST_HAS_THREADS.cc:16:4: Warnung: #warning "_REENTRANT defined" test-BOOST_HAS_THREADS.cc:24:4: Warnung: #warning "BOOST_HAS_THREADS defined" I have no idea what the gcc developers recommend in order to detect multi-threading support or if this should be reported to the gcc developers as a bug. But it will certainly break many programs using Boost. A user can work around this problem by either including boost/config.hpp before any other headers (even Boost headers since boost/lexical_cast.hpp, for example, includes string before boost/config.hpp). Or the user builds everything with MT-support, even if the program itself is single threaded. Neither workaround is satisfying. Regards Christoph PS: FWIW, I could trace back the problem to a change in include/c++/i686-pc-linux-gnu/bits/gthr-default.h. This change was discussed in http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01607.html. -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

4 21

Patch for linker problems wiith date_time
by Matthias Troyer 02 Jul '04

02 Jul '04

Dear Boosters, There are a few inline statements missing in the new version of the date_time library, causing multiple definitions and linkage problems. I have attached a diff. Matthias cvs diff -u boost/date_time/posix_time/date_duration_operators.hpp Index: boost/date_time/posix_time/date_duration_operators.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/date_time/posix_time/ date_duration_operators.hpp,v retrieving revision 1.1 diff -u -r1.1 date_duration_operators.hpp --- boost/date_time/posix_time/date_duration_operators.hpp 30 Jun 2004 00:11:11 -0000 1.1 +++ boost/date_time/posix_time/date_duration_operators.hpp 1 Jul 2004 14:31:57 -0000 @@ -17,39 +17,39 @@ /*** ptime operator functions ***/ // ptime & months - ptime operator+(const ptime& t, const boost::gregorian::months& m) + inline ptime operator+(const ptime& t, const boost::gregorian::months& m) { return t + m.get_offset(t.date()); } - ptime operator+=(ptime& t, const boost::gregorian::months& m) + inline ptime operator+=(ptime& t, const boost::gregorian::months& m) { // get_neg_offset returns a negative duration, so we add return t += m.get_offset(t.date()); } - ptime operator-(const ptime& t, const boost::gregorian::months& m) + inline ptime operator-(const ptime& t, const boost::gregorian::months& m) { // get_neg_offset returns a negative duration, so we add return t + m.get_neg_offset(t.date()); } - ptime operator-=(ptime& t, const boost::gregorian::months& m) + inline ptime operator-=(ptime& t, const boost::gregorian::months& m) { return t += m.get_neg_offset(t.date()); } // ptime & years - ptime operator+(const ptime& t, const boost::gregorian::years& y) + inline ptime operator+(const ptime& t, const boost::gregorian::years& y) { return t + y.get_offset(t.date()); } - ptime operator+=(ptime& t, const boost::gregorian::years& y) + inline ptime operator+=(ptime& t, const boost::gregorian::years& y) { return t += y.get_offset(t.date()); } - ptime operator-(const ptime& t, const boost::gregorian::years& y) + inline ptime operator-(const ptime& t, const boost::gregorian::years& y) { // get_neg_offset returns a negative duration, so we add return t + y.get_neg_offset(t.date()); } - ptime operator-=(ptime& t, const boost::gregorian::years& y) + inline ptime operator-=(ptime& t, const boost::gregorian::years& y) { // get_neg_offset returns a negative duration, so we add return t += y.get_neg_offset(t.date());

2 1

Re:[boost] Serialization of infinite double - from comp.lang.c++
by Robert Ramey 02 Jul '04

02 Jul '04

>> If you want to store a special 'token' to indicate 'infinity', you'll >> need to specifically parse for it. >Perhaps I could alter the behavior of the "ostream& operator<<(ostream&, >double)" (and istream)? >Any other idea for a solution would of course be just as welcome.... Problem - serialization of a float/double with an Infinite or Nan value Fails with a text archive. This is due to the fact that the this archive class depends upon implementation of stream I/o which apparently doesn't consider these values for floats. I would suggest making a small derivation from the standard text archive which overrides the existing implementation of the load(float &) and load(double &) with a slightly more elaborate one which can handle these values. There is an example in the manual on how to do this. I'm no sure whether or not this facility should be part of the standard text archive or not. Fast workaround - use the native binary archive which just saves/loads the raw bits without trying to interpret them. Robert Ramey

1 0

[Boost-bugs] [ boost-Bugs-984124 ] pool::purge_memory() does not reset next_size
by SourceForge.net 02 Jul '04

02 Jul '04

Bugs item #984124, was opened at 2004-07-02 08:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=984124&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pool::purge_memory() does not reset next_size Initial Comment: Calling purge_memory() does not reset next_size in the memory pool implementation. This means that repeatedly allocating then calling purge_memory() causes the pool to allocate a buffer of double the size each time, even though the number of objects remains small. Thanks, Edmund Kapusniak. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=984124&group_i… ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

CVS Fingerprint problems
by Fernando Cacciola 02 Jul '04

02 Jul '04

Hi, I'm trying to commit something to CVS but I get a warning from TortoiseCVS saying that the server fingerprint has changed. This is wrong right? TIA Fernando Cacciola SciSoft

2 2

logging library
by John Torjo 02 Jul '04

02 Jul '04

Dear boosters, Finally, found some time to work on the logging library ;) (for those interested - find it at http://groups.yahoo.com/group/boost/files/logging.zip or http://www.torjo.com/code/logging.zip) note: this first draft works only for Win32 :( In short, it makes it very easy to log messages, while being efficient. And on top of that, it's thread-safe. Table of contents: ****** Declaring/defining logs ****** Log hierarchies ****** Modifier/ Log functions ****** Enabling/disabling of logs ****** Example ****** Declaring/defining logs Every log has: - a unique ID, by which you refer when you write to it - a name, by which you can modify its behavior (for example, enabling/disabling). The name is very useful so that you can manipulate multiple logs at once (for instance, disable multiple logs at once) and to be externally known - to easily manipulate logs at run-time. Also, this way is also easier to form hierarchies of logs (see below). Cutting to the chanse: // declare a log, in a header file BOOST_DECLARE_LOG(dbg) // define the log, in a source file BOOST_DEFINE_LOG(dbg, "app.dbg") // writing to the log BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; ****** Log hierarchies Logs can be hierarchical. In a hierarchy, a log inherits all anscestors' behaviors. Log A is said to be a descendant of Log B if when B's name starts with A's name (example: "app.charts.gui.dbg" is a descendant of "app.charts", but not a descendant of "app.err") When manipulating logs, you're always manipulating a hierarchy - the wildcard '*' stands for "anything" - see below. ****** Modifier/ Log functions When a message is written to a log, the following will happen: - first, check if the log is enabled. If so, continue. Otherwise, do nothing. - run all modifiers for this message - run all log functions for this message A modifier is a function that can modify the original message before it's printed to any destination. Examples can be: prefix the message with the current time, or prefix the message with the current thread ID. The log function is a function that will actually print this message to a destination. An example: void write_to_cout(const std::string &, const std::string &msg) { std::cout << msg; } When setting modifier/log functions, you're manipulating hierarchies of logs. Example: // add this modifier to all logs that start with "app" name add_modifier_func("app*", &write_prefix); // write all messages to cout add_log_func("*", write_to_cout); ****** Enabling/disabling of logs By default, all logs are enabled. You can specifically enable/disable some of them - wildcards work. Example: // disable all logs disable_logs("*"); // enable all dbg logs enable_logs("*dbg*"); Note that enabling/disabling is VERY EFFICIENT. In case a log is not enabled, the code after BOOST_LOG(...) is not executed AT ALL. Example: BOOST_LOG(app) << some_time_consuming_msg << std::endl; If 'app' is disabled, some_time_consuming_msg will not be executed. ****** Example // full sample found in logging.zip // Modifiers for all: // [type_of_message] original_message append_enter_if_needed add_modifier_func("*", &prefix_time, std::numeric_limits<int>::max() ); add_modifier_func("*", &append_enter); // Modifiers for app and its ascendants // <time> [type_of_message] original_message append_enter_if_needed add_modifier_func("app*", &write_prefix); // Modifiers for "app" only // <time> [Thread ID] [type_of_message] original_message append_enter_if_needed add_modifier_func("app", &prepend_thread_id, 0); // Log Functions // all messages are written to cout add_log_func("*", write_to_cout); // "app*" messages are written to file as well add_log_func("app*", write_to_file); // 'app' only and dbg messages are written to Output Debug Window as well add_log_func("app", write_to_dbg_wnd); add_log_func("*dbg*", write_to_dbg_wnd); int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing" << i << '-' << j << '-' << k; // written to both cout & the file & Output Debug Window BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; BOOST_LOG(warn) << "Logged-on Users approach max. limit"; BOOST_LOG(err) << "Too many users!"; BOOST_LOG(charts::gui) << "Creating main window" << std::endl; BOOST_LOG(charts::dbg) << "A debug msg coming from {charts} module" ; BOOST_LOG(charts::gui) << "Destroying main window" << std::endl; // disable all descendants of 'app' (not the 'app' itself) disable_logs("app.*"); BOOST_LOG(dbg) << "this won't be written" << std::endl; BOOST_LOG(app) << "However, this msg. will" << std::endl; enable_logs("app.dbg"); // specifically, only dbg log is enabled back now BOOST_LOG(dbg) << "this will be written - this log just got enabled" << std::endl; BOOST_LOG(err) << "this still won't be written" << std::endl; enable_logs("app.*"); disable_logs("app.dbg"); // now, all logs are back to the 'enabled' state BOOST_LOG(err) << "this will be written - all logs are enabled" << std::endl; // disable all logs disable_logs("*"); BOOST_LOG(err) << "this won't be written" << std::endl; BOOST_LOG(app) << "neither will this" << std::endl; BOOST_LOG(dbg) << "or this..." << std::endl; BOOST_LOG(warn) << "or this..." << std::endl; BOOST_LOG(info) << "or this..." << std::endl; // enable all dbg logs enable_logs("*dbg*"); BOOST_LOG(app) << "this won't be written" << std::endl; BOOST_LOG(dbg) << "this will be written" << std::endl; BOOST_LOG(info) << "this won't be written" << std::endl; // enable info log enable_logs("*info*"); BOOST_LOG(info) << "a simple info" << std::endl; /*** Console 18:59:44 [app] [Thread 1384] testing1-2-3 18:59:44 [app.dbg] this is a debug message, i=1 18:59:44 I just wanted to tell you something.... 18:59:44 [app.warn] Logged-on Users approach max. limit 18:59:44 [app.err] Too many users! 18:59:44 Creating main window 18:59:44 A debug msg coming from {charts} module 18:59:44 Destroying main window 18:59:44 [app] [Thread 1384] However, this msg. will 18:59:44 [app.dbg] this will be written - this log just got enabled 18:59:44 [app.err] this will be written - all logs are enabled 18:59:44 [app.dbg] this will be written 18:59:44 a simple info */ /*** Output Debug Window 19:00:03 [app] [Thread 1384] testing1-2-3 19:00:03 [app.dbg] this is a debug message, i=1 19:00:03 A debug msg coming from {charts} module 19:00:03 [app] [Thread 1384] However, this msg. will 19:00:03 [app.dbg] this will be written - this log just got enabled 19:00:03 [app.dbg] this will be written */ /*** out.txt file 19:00:03 [app] [Thread 1384] testing1-2-3 19:00:03 [app.dbg] this is a debug message, i=1 19:00:03 [app.warn] Logged-on Users approach max. limit 19:00:03 [app.err] Too many users! 19:00:03 [app] [Thread 1384] However, this msg. will 19:00:03 [app.dbg] this will be written - this log just got enabled 19:00:03 [app.err] this will be written - all logs are enabled 19:00:03 [app.dbg] this will be written */ There's some more work - the docs also ;) , but I'm pretty happy with the first draft. What do you all think? Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

5 10

[program_options] Darwin/Unicode/DLL failure
by Vladimir Prus 02 Jul '04

02 Jul '04

Hello! As shown in http://tinyurl.com/2q5xe that program_options fails unicode_test_dll on darwin. It's the only failure there, does not happen with statically linked version, and happens at runtime. For some reason conversion from or to unicode fails. Since it's runtime failure, I have no idea what could be wrong, and why it only happens in DLL. I'd really appreciate if somebody has a clue. Even knowning what's being converted, and at which character the codecvt facet fails might help. Thanks in advance, Volodya

1 0

Re: Learning boost::MPL
by Dan 02 Jul '04

02 Jul '04

Thanks Maxim, I appreciate the help. I tried the code out, it works well, but I must confess that I don't understand how it works. It seems you start it at begin+1. I don't know why but it's probably related to the next question. What is happening on this line? mpl::plus<mpl::deref<mpl::_2>, mpl::_1> As near as I can tell you deref the iterator in <_2> and add that with _1. How does this _1 and _2 stuff work anyway? Thanks again! -Dan

3 2

logging library v1.1 - with documentation!
by John Torjo 02 Jul '04

02 Jul '04

Dear boosters, Worked some more on the logging library, and here's what's new: - added ***documentation*** - added samples - made static library (improved compilation times) - added efficient thread-safe logger, which does the logging on a dedicated thread (in order to be as fast as possible, it caches multiple log messages - which could be coming from multiple threads, and has a dedicated thread, which once at X milliseconds, writes them) Get it from: http://groups.yahoo.com/group/boost/files/logging.zip or http://www.torjo.com/code/logging.zip Looking forward to your feedback. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 5

min/max, revolutions
by Eric Niebler 02 Jul '04

02 Jul '04

I've made one more small tweak to the min/max fix. I have relocated the BOOST_USING_STD_MIN and BOOST_USING_STD_MAX macros to their rightful place in the config headers and removed boost/minmax.hpp. I have fixed all the code affected by this change. I have also changed the coding guidelines to say to #include config.hpp instead of minmax.hpp. I have also (hopefully!) fixed the problem with gcc-2.95/STLPort, although I don't have that platform so I couldn't test my changes. Thanks for your patience while I work these kinks out. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

Or, maybe even, try_scoped_lock : private basic_lock { ... try_scoped_lock (mutex& m) : basic_lock(m, 0) {} bool try_lock() { basic_lock.try_lock(); } // No lock() for try_scoped_lock } Then, user-oriented interfaces would be pristine clean for average users and the majority of uses without affecting/complicating underlying implementation and disadvantaging the advanced/tricky users. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Batov, Vladimir Sent: Friday, 2 July 2004 7:40 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? I am thinking maybe technically it would be much easier and cleaner to implement one basic_lock (modeled on the current timed_lock) and then provide specializations (you see, I am avoiding "refinement" :-) ) of it to the user like: try_lock : public basic_lock { ... try_lock(mutex& m) : basic_lock(m, 0) {} } Then, 1. underlying implementation would be much simpler and without duplication as it'd always operate with basic_lock (good for maintainers/implementers); 2. average users would still have friendly and simple interface; 3. advanced users might do much more tricky stuff by simply cutting to the bone and using basic_lock. Just a thought. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Batov, Vladimir Sent: Friday, 2 July 2004 7:25 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition) template <typename ScopedLock> bool timed_wait(ScopedLock& lock, const xtime& XT); Looking at the code it does appear to require timed_lock either: template <typename L> bool timed_wait(L& lock, const xtime& xt) { if (!lock) throw lock_error(); return do_timed_wait(lock.m_mutex, xt); } What am I missing? BTW. How can I get to have look at the development branch? I went to http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: >>Well, as you point out, try_lock is like a timed_lock with >>time = 0, and lock is like a timed_lock with time = infinity, >>so why not give timed_lock both lock() and try_lock() >>methods as shorthand notation for lock(m, t=0) and >>lock(m, t=infinity)? > > > [Batov, Vladimir] Because, in my view, it violates the fundamental (and > I think widely accepted) OO design principle (guideline?) that in simple > terms can be expressed as "one class, one responsibility". Names like > Bertrand Meyer, Herb Sutter and many others immediately come to mind. > > We can either achieve that by having a universal lock (with timed_lock > as the basis) and shorthand notations in separate derived classes (lock, > timed_lock and try_lock) or by keeping those three completely unrelated > (probably at the expense of some code/functionality duplication). I am > personally leaning towards latter, as even though technically all three > concepts are related, from the user point of view they are distinct. > > >>The argument for try_lock not having a blocking lock() method, >>which you seem to stress more often, is much clearer; I'm much >>more inclined to agree with you there. > > > [Batov, Vladimir] Thank you. I feel that it is important that every > class does what it promises to do. No more, no less. For what it's worth, heres a use case I just ran across illustrating why timed_lock should have a blocking lock() method and/or a blocking locked constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

I am thinking maybe technically it would be much easier and cleaner to implement one basic_lock (modeled on the current timed_lock) and then provide specializations (you see, I am avoiding "refinement" :-) ) of it to the user like: try_lock : public basic_lock { ... try_lock(mutex& m) : basic_lock(m, 0) {} } Then, 1. underlying implementation would be much simpler and without duplication as it'd always operate with basic_lock (good for maintainers/implementers); 2. average users would still have friendly and simple interface; 3. advanced users might do much more tricky stuff by simply cutting to the bone and using basic_lock. Just a thought. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Batov, Vladimir Sent: Friday, 2 July 2004 7:25 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition) template <typename ScopedLock> bool timed_wait(ScopedLock& lock, const xtime& XT); Looking at the code it does appear to require timed_lock either: template <typename L> bool timed_wait(L& lock, const xtime& xt) { if (!lock) throw lock_error(); return do_timed_wait(lock.m_mutex, xt); } What am I missing? BTW. How can I get to have look at the development branch? I went to http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: >>Well, as you point out, try_lock is like a timed_lock with >>time = 0, and lock is like a timed_lock with time = infinity, >>so why not give timed_lock both lock() and try_lock() >>methods as shorthand notation for lock(m, t=0) and >>lock(m, t=infinity)? > > > [Batov, Vladimir] Because, in my view, it violates the fundamental (and > I think widely accepted) OO design principle (guideline?) that in simple > terms can be expressed as "one class, one responsibility". Names like > Bertrand Meyer, Herb Sutter and many others immediately come to mind. > > We can either achieve that by having a universal lock (with timed_lock > as the basis) and shorthand notations in separate derived classes (lock, > timed_lock and try_lock) or by keeping those three completely unrelated > (probably at the expense of some code/functionality duplication). I am > personally leaning towards latter, as even though technically all three > concepts are related, from the user point of view they are distinct. > > >>The argument for try_lock not having a blocking lock() method, >>which you seem to stress more often, is much clearer; I'm much >>more inclined to agree with you there. > > > [Batov, Vladimir] Thank you. I feel that it is important that every > class does what it promises to do. No more, no less. For what it's worth, heres a use case I just ran across illustrating why timed_lock should have a blocking lock() method and/or a blocking locked constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Serialization of infinite double - from comp.lang.c++
by Jeff Flinn 01 Jul '04

01 Jul '04

I'm posting this message from Gustav Lead from comp.lang.c++ while he gets access to boost devel and/or user mailing lists. Jeff Flinn ---------------------------------- Hi all, I have trouble reading back floating point data from a file. It appears as if the tokens for positive and negative infinity (1.#INF and -1.#INF) that my implementation writes get misinterpreted (to 1.0 and -1.0) when I try to read them back in. #include <fstream> #include <limits> void somefunction() { double d_infinity = std::numeric_limits<double>::infinity(); std::ofstream output; output.open("file.txt"); output << d_infinity; output.close(); double d_test1 = 0; std::ifstream input; input.open("file.txt"); input >> d_test1; input.close(); } The contents of "file.txt" is "1.#INF". At the end of the function the value of d_test1 is 1.0 . Trying to read in more data after that will fail, because the "#INF" fragment remains in the stream. Is this a problem of my STL implementation (I am using MSVC 7.1), or do I have to make some change to my code to get this to work correctly? Thanks in advance, G L "Mike Wahler" <mkwahler(a)mkwahler.net> wrote in news:xTIEc.470$oD3.371@newsread1.news.pas.earthlink.net: > > No, this is by design. > If you want to store a special 'token' to indicate 'infinity', you'll > need to specifically parse for it. > > Typically numeric input is handled more robustly by reading a 'line' > as a string, and using conversion functions after the fact (e.g. > 'strod()' or an istringstream extractor). To check for your > 'infinity' token, just search the string for that first. > > -Mike Thanks for your answer, Mike! Unfortunatly this is not an option for me, because I am using a serialization library (Boost::Serialization currently at http://www.rrsd.com/boost/) and I have to rely on the STL stream library operators to read back all of their repective data as they wrote it into the stream and to properly restore the state of the object. Perhaps I could alter the behavior of the "ostream& operator<<(ostream&, double)" (and istream)? I think overloading would be a redefintion and is out of the question (or is it???) unless I make some kind of wrapper for doubles, but maybe it is possible to do this with locales (or facets?) ? Locales are really terra incognita for me, so I'd really like some advice if this is a viable option at all, before I try to go down that path. Any other idea for a solution would of course be just as welcome.... Thanks, GL

1 0

Re: Learning boost::MPL (Daniel Wallin)
by Dan 01 Jul '04

01 Jul '04

Hi Daniel, I tried your code as well and it works fine (it's also nice and compact) >I don't know why you are using iter_fold instead of just fold here, but >anyway: Oops, don't assume I know what I'm doing, because I don't! Yesterday was the first I ever heard of boost MPL. Whats the difference between iter_fold and fold? I replaced iter_fold with fold in your code and it works as well. Thanks, -A fellow Daniel :)

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

> Well, as you point out, try_lock is like a timed_lock with > time = 0, and lock is like a timed_lock with time = infinity, > so why not give timed_lock both lock() and try_lock() > methods as shorthand notation for lock(m, t=0) and > lock(m, t=infinity)? [Batov, Vladimir] Because, in my view, it violates the fundamental (and I think widely accepted) OO design principle (guideline?) that in simple terms can be expressed as "one class, one responsibility". Names like Bertrand Meyer, Herb Sutter and many others immediately come to mind. We can either achieve that by having a universal lock (with timed_lock as the basis) and shorthand notations in separate derived classes (lock, timed_lock and try_lock) or by keeping those three completely unrelated (probably at the expense of some code/functionality duplication). I am personally leaning towards latter, as even though technically all three concepts are related, from the user point of view they are distinct. > The argument for try_lock not having a blocking lock() method, > which you seem to stress more often, is much clearer; I'm much > more inclined to agree with you there. [Batov, Vladimir] Thank you. I feel that it is important that every class does what it promises to do. No more, no less.

2 1

Converting Boost.Threads documentation to BoostBook
by Michael Glassford 01 Jul '04

01 Jul '04

I've just checked in the Boost.Threads documentation in BoostBook format and changed doc\src\boost.xml appropriately; is there anything else I need to do? Also, is the BoostBook documentation being regularly generated somewhere so that I can take a look at it and make sure everything is working properly somewhere besides my machine? Mike

4 4

gcc thread local storage
by Neal D. Becker 01 Jul '04

01 Jul '04

I know almost nothing about threads. Still I thought this link might be of interest for boost::thread. I'm guessing that the term "Thread Local Storage" is the same as "Thread Static Storage". http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

[Christopher Currie] In the need of extreme memory efficiency and speed: I already have, from prior use, a scoped_try_lock 'l' around my mutex, currently unlocked. I need to lock my mutex in a blocking fashion. I do not wish to pay the memory and time cost to create an instance of scoped_lock just to do this. I therefore call 'l.lock()' and not 'l.try_lock()'. [Batov, Vladimir] I am sorry but I am far from being convinced that "extreme memory efficiency" can be achieved by saving on one lock. Locks are very transient creatures and created on the stack. Commonly the stack is predefined by OS regardless if you use it or not. Consequently, even when you do not create another object on the stack, that memory is not available to you for anything else anyway. Even if it is, I greatly doubt that that approach is the right approach to achieve efficiency. The common approach would be to worry about the right design first and foremost, then run profilers/monitors/tests to see where we actually can save memory/gain performance. Twisting design for the sake of perceived performance/memory gains is often (I'd say always) a very bad idea. Even if you do not buy into my arguments in the prev. paragraph, you'll probably agree it'll be unfair to expect that the majority of library users and overall general-purpose library design need to pay the price of accommodating your very specific requirements. For example, general memory allocation is often slow for me. Then, I write my own special memory allocator. I am not asking for the general-purpose allocator to be changed. ... [Christopher Currie] Constructor parameters are, admittedly, a different discussion, and most of them boil down to syntactic sugar for a non-locking constructor and a call to some locking operation, blocking or otherwise. But (IMO) it's a useful syntactic sugar that *can* if used properly make programs less cumbersome to construct without sacrificing correctness or clarity. [Batov, Vladimir] I am not against syntactic sugar if it is in line with what is reasonably expected from a class. However, I am against syntactic sugar which is not relevant to class functionality. Like I am happy if I can simply give my credit card to a taxi driver and not worry about having cash. However, I am not sure if I'd like that driver singing. As far as S/W design is concerned, I'd prefer a taxi driver class (with its responsibilities) and a singer class (with its responsibilities). We all know how to blend those two classes if we ever need that.

2 1

min, max, GCC 2.95.3, and STLport
by Doug Gregor 01 Jul '04

01 Jul '04

The new handling of min/max seems to break under GCC 2.95.3 with STLport. I'm not quite sure _why_ it doesn't work (I don't have the compiler around), but you can see the failure here: http://tinyurl.com/ytdlf Perhaps someone with that compiler/lib combination could get preprocessed output for the problem area so we could see what's happening? Doug

4 5

Learning boost::MPL
by Dan 01 Jul '04

01 Jul '04

I'm trying to use iter_fold with a vector_c to compute the sum of all of the integers in the container. What I have is: template<typename Sequence> struct sum { typedef typename mpl::iter_fold< Sequence, typename mpl::begin<Sequence>::type, mpl::plus< mpl::deref<_1>, mpl::deref<_2> >; // ^ what should this really be? > // what do i put after here? }; Which obviously won't work. I don't know how to keep a running total as I iterate over the sequence with plus. Help! Thanks, -Dan

3 2

ccref
by alnsn＠yandex.ru 01 Jul '04

01 Jul '04

This is not a typo, I'm trying to emphasize that ref, cref, ... sequence lacks one element which imposes more strict requirements on its argument. According to IQ tests logic that sequence should be continued with ccref :) If seriously, cref allows silent binding of a temporary to a reference. Apparently, this is not always fine. Inspired by N1610 (thanks to Dave and Gary) I've tried to detect both const and non-const rvalues. I didn't yet opened my copy of the standard to check it but the code seems to work on g++ 3.2.2, g++ 3.4.0, Intel 8.0 (all under linux) and Comeau online. #include <boost/ref.hpp> template<class T1, class T2> struct enable_if_same { }; template<class T> struct enable_if_same<T,T> { typedef int type; }; template<class T> boost::reference_wrapper<T const> const ccref(T volatile& r, typename enable_if_same<T,T const>::type = 0) { return boost::reference_wrapper<T const>(const_cast<T const&>(r)); } struct convertible_to_int { operator int() const { return 0; } }; template<class T> boost::reference_wrapper<T const> const ccref(T const volatile& r) { return boost::reference_wrapper<T const>(const_cast<T const&>(r)); } int rvalue() { return 0; } int const const_rvalue() { return 0; } int main() { int i; int const j = 0; ccref(i); ccref(j); // Try uncommenting any of these lines: // ccref(rvalue()); // ccref(const_rvalue()); } -- Alexander Nasonov

3 4

Links at ACCU
by David Abrahams 01 Jul '04

01 Jul '04

Hi, I recently got this request from the ACCU website admins: Please take a look at www.accu.org/terse/cpp.htm and let me know how the Boost library/people would like to be represented on www.accu.org/terse/cpp.htm. So I figured I'd ask. Anyone have an opinion? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

5 4

RE: [boost] Re: Cvs tag dependency
by Rozental, Gennadiy 01 Jul '04

01 Jul '04

> "Rozental, Gennadiy" <gennadiy.rozental(a)thomson.com> writes: > > > Hi, > > > > Inn a light of recent discussion on earlier freezing, I > have following > > question/proposition: > > > > Is it exist in Boost.Build or could we add feature that allow us to > > specify cvs tag dependency as a dependency grist? > > I _think_ what you're proposing is interesting, but the means > of getting there may be completely inappropriate for > Boost.Build, if I understand it at all. Why don't you try to > say what you're trying to accomplish without trying to design > the Boost.Build feature? I want to be able to use regression testing facility not only for HEAD cvs state. > Are you trying to get cvs checkout > actions into the build system? Namely. I want build system be aware about different versions of files/components and want to be able to specify which version I prefer to use for this particular test. > If so, why? What's wrong with doing > > cvs update -rwhatever_tag > before kicking off the test? Nothing. I just want it happened automatically on a computer that performs regression testing, depends on a rule defined in a Jamfile. > Dave Abrahams Gennadiy.

3 2

[MPL] rational_c and fixed_c
by Cromwell Enage 30 Jun '04

30 Jun '04

A while back it was mentioned that boost::mpl::rational_c and boost::mpl::fixed_c needed redesigning. Before I attempt to tackle this task anymore than I already have, I should have some questions answered. 1. For those compilers for which BOOST_NO_LIMITS is defined, I've learned that there is no way to include a floating-point number in an integral constant expression. Does this mean that no matter how I define fixed_c::value, I cannot pass fixed_c as a template argument to a metafunction that ordinarily takes integral_c as input? Do I have to duplicate the functionality as a result? If so, what should be the naming convention for these new metafunctions? 2. Should I define fixed_c in terms of rational_c, to reduce the amount of functionality I may need to duplicate? Something like this: template <typename IntType, IntType N, IntType PowerOf10> struct fixed_c { typedef rational_c<IntType,...,...> type; }; 3. Eventually the compile-time rational-number representation will need to be converted to a runtime floating-point value. Should I define this conversion function within rational_c (which means an additional template parameter, with either function or class scope, defining the return value type), within a wrapper struct, or somewhere else? And how? 4. I only have to deal with rational numbers, right? I don't have to worry about accurately representing a transcendental number or a complex-number expression? TIA! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer

3 7

Implicit failures in MetaComm regression tests?
by Doug Gregor 30 Jun '04

30 Jun '04

The Boost.Function test case "lambda_test" for intel-win32-7.1-vc6 (and its STLport variant) come out as unexpected passes. I'd like to move these over to explicit passes, but they don't seem to be marked as expected failures in status/explicit-failures-markup.xml. How can I make these expected passes, to get that nice cushy all-green feeling? Doug

3 4

Cvs tag dependency
by Rozental, Gennadiy 30 Jun '04

30 Jun '04

Hi, Inn a light of recent discussion on earlier freezing, I have following question/proposition: Is it exist in Boost.Build or could we add feature that allow us to specify cvs tag dependency as a dependency grist? Example1: Jamfile ------- MY_SRCS = .... tag_to_test = my_lib_dev # HEAD run my_test : <tag:$(tag_to_test)>$(MY_SRCS) Now If I want to test my new development branch I just set tag to appropriate value. Example2: Jamfile ------- exe my_test : ...sources... <tag:1_31_0><lib>../build/boost_unit_test_framework Now I want stable version of library - I specify which one I want. Example3: Jamfile ------- exe my_test : ...sources... <tag:1_30_0>...abc.h Here I know my code works with that version of header file I want to use it specifically. And so on. This feature could allow us to: 1. Test development branches for regressions 2 .Test new features before moving it in cvs HEAD 3. Depend on stable version of dependency, without need to keep up with changes in it. 4. Test development version Boost.Test with stable version of it e.t.c I am sure it's not easy to do. But may be it worth a shot. Gennadiy.

3 2

boost::variant visitor member instantiation question
by craig perras 30 Jun '04

30 Jun '04

Hello - I want to do type conversions (checked at compile-time) using boost::variant. So I naively made a 'convert' visitor, which has designed to (hopefully) safely convert the variant value to another type (eg: a client might try to assign the variant's int value to an unsigned short). For instance: typedef boost::variant < std::string, int, double > ParamValue; // ----- ConvertParamValueVisitor //T is the type which will be assigned the variant's value //V is the Variant/Visitor template<typename T> struct ConvertParamValueVisitor<T> { typedef ConvertParamValueVisitor self; typedef void result_type; self( T*& val ) : value_(val) {} template<typename V> result_type operator()( const V& v, typename boost::enable_if<TypeTraits::is_arithmetic<V> >::type* dummy = 0 ) const { *value_ = boost::numeric_cast<T>(v); } template<typename V> result_type operator()( const V& v, typename boost::enable_if<TypeTraits::is_string<V> >::type* dummy = 0 ) const { *value_ = v; } private: T*& value_; }; It seems boost::variant will instantiate all members for all variant types, even the ones I try to suppress using enable_if. To work around this, I've tried various things, like specializing ConvertParamValueVisitor based on T, using lazy_enable_if, etc. Here's one attempt: // ----- ConvertParamValueVisitor //T is the type which will be assigned the variant's value //V is the Variant/Visitor //not implemented template<typename T, class Enable = void> struct ConvertParamValueVisitor; //ConvertParamValueVisitor int, double: use numeric cast template<typename T> struct ConvertParamValueVisitor<T, typename boost::enable_if<TypeTraits::is_arithmetic<T> >::type > { typedef void result_type; typedef ConvertParamValueVisitor self; self( T*& val ) : value_(val) {} template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_arithmetic<V> >::type* dummy = 0 ) const { *value_ = boost::numeric_cast<T>(val); } //not implemented template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_string<V> >::type* dummy = 0 ) const; private: T*& value_; }; //ConvertParamValueVisitor string template<typename T> struct ConvertParamValueVisitor<T, typename boost::enable_if<TypeTraits::is_string<T> >::type > { typedef void result_type; typedef ConvertParamValueVisitor self; self( T*& val ) : value_(val) {} //not implemented template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_arithmetic<V> >::type* dummy = 0 ) const; template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_string<V> >::type* dummy = 0 ) const { *value_ = val; } private: T*& value_; }; Is there any way to get something like this to work? Am I simply mis-applying boost::variant? I could of course just throw an exception in the unsupported/not implemented methods above, but I'd like this checked at at compile time if possible. (note that my question is generally applicable to visitors, not just to boost::variant). thanks! --craig __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

1 0

Boost Signal Bug
by Neal Coombes 30 Jun '04

30 Jun '04

I've experienced the same problem discussed on June 3rd titled "Bug, signals, use of default Combiner" http://thread.gmane.org/gmane.comp.lib.boost.devel/103903 . I would have just replied except its a little old, thus a new thread. Doug Gregor wrote: > We intentionally did not return a default-constructed value because > the returned type might not have a default constructor. Granted, this > case might be sufficiently rare to justify using your version of > last_value. I would like to say a few things about this and offer an alternative solution. First, I think not returning a default constructed value is the correct approach with the last_value combiner for the reasons you've mentioned. I don't think the bug is with the last_value combiner, but with the fact that the last_value combiner is the default combiner (ok an exception rather than an assert would probably be better). However, I would venture to claim that a signal being called without any slots is not a rare case. In fact I'd guess that might be the most likely case. Certainly, as a library writer, I cannot assume that all the signals I provide to my users are going to be used in every application. My suggestion is to provide a default combiner that does the bare minimum, just call the slots: namespace boost { struct default_combiner { typedef void result_type; template<typename InputIterator> result_type operator()(InputIterator first, InputIterator last) const { while (first != last) *first++; } }; } I believe this would solve the problem without restricting use of default signals to objects with default constructors, or to signals with at least one slot connected.

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 30 Jun '04

30 Jun '04

1. Oh, c'mon, I never implied that your design was "dubious and likely incorrect". It was said in the context of operator[] for std:list. 2. IMHO for a library to be accepted, embraced, popular, survive it has to be suitable/convenient/intuitive for 80% of the users. The library should not go out of its way to satisfy esoteric requirements of 20% at the expense of clarity/simplicity/good design. Or example, std:auto_ptr is not for everyone and not always work where I'd like it to work. It does not mean std::auto_ptr needs to sacrifice its efficient and minimalistic beauty to make me happy. Getting back to Boost.Threads I'd still like to see a compelling example where I'd need to declare try_lock but twist its intuitive functionality into behaving like scoped_lock (that is blocking until locked). -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matt Hurd Sent: Wednesday, 30 June 2004 10:42 AM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Boost.Threads: Do we need all those mutexes? On Wed, 30 Jun 2004 10:17:04 +1000, Batov, Vladimir <vladimir.batov(a)ca.com> wrote: > > Why give the user an alternative with is > dubious and likely incorrect? It is a pattern of need for multithreaded programming where I work to require single and multithreaded awareness for objects where performance excludes the option of using separate object instances. I don't think the design is dubious or incorrect it is mandated by the business requirements. Though most of my designs usually are incorrect or dubious ;-) I just call those tactical :-) matt. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[Graph] problem with set_property method when using subgraph?
by Daniel Lou 30 Jun '04

30 Jun '04

Hi, I wanted to set meaningful names for individual subgraphs but I failed with the following test code.... ---------------------------------------------------------------------------- --------------- typedef adjacency_list<vecS, vecS, directedS,no_property, no_property, property<graph_name_t, string> > mygraph_t; typedef subgraph < graph_t > mysubgraph_t; graph_t g; boost::set_property(g, graph_name, "graph"); // **** this is O.K. mysubgraph G; boost::set_property(G, graph_name, "subgraph"); // **** Error C2784 cout << boost::get_property(G, graph_name) << endl; ---------------------------------------------------------------------------- - I use .NET 2003. The error message says: could not deduce template argument for 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,Edg eProperty,GraphProperty,EdgeListS> &' from 'mysubraph_t' Any thoughts? Thanks, Daniel

2 1

[BGL] remove_edge bug
by Vladimir Prus 30 Jun '04

30 Jun '04

Jeremy, I think your reversion 1.120 of detail/adjacency_list.hpp: 2004-04-01 05:30 jsiek * detail/adjacency_list.hpp: fixed remove_edge for bidirectional graphs actually breaks remove_edge in a different way. Please take a look at http://zigzag.cs.msu.su:7813/program_graph.cpp The code there add two vertices, an edge between them, and then removes the edge. After that 'num_edges' returns 1, not 0 as expected. I seems like now remove_edge removes elements from out_edges and in_edges storage, but not from global edges vector. Is it possible to fix this problem? TIA, Volodya

2 3

[BGL] Unused parameter "inf" in dijkstra_shortest_paths?
by Douglas Gregor 30 Jun '04

30 Jun '04

Hmmm, this could be a bug, but I don't have time to look into it now: /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, size_t, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::edge_length_t>, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = TravelTimePropertyMap, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' Doug

2 1

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 30 Jun '04

30 Jun '04

>>" Thread-safety should not be a run-time configurable property." > I think this is somewhat incorrect as absolutes usually are. Well, I'll probably lose the fairly abstract discussion of general incorrectness of absolutes. :-) I just think that compile-time vs. run-time is a pragmatic choice. Why give the user an alternative with is dubious and likely incorrect? For that reason std::list does not provide operator[] even though it could. Surely, one could come up with his/her design that would "require" such an operator for std::list. Does it invalidate the decisions STL designers made? I do not think so. That is why I am suspicious of temptations to lump distinctly different functions of scoped_lock, try_lock and timed_lock into one universal blob. V.

3 2

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 30 Jun '04

30 Jun '04

> bool foo(bool threadsafe) > { > mutex::scoped_lock l(m, !threadsafe); > } I am not sure if the example above is appropriate and indicative of the problem we are trying to solve. Thread-safety should not be a run-time configurable property. Like we do not decide on the fly (at run-time) if our ref.-counting class is to be thread-safe or not. All that is resolved at compile time. More so, that still can be solved with statically defined lock/nolock constructors: bool foo(bool some_condifion) { mutex::scoped_lock l(m, boost::nolock); if (some_condition) l.lock(); } 2. I feel that our assumptions of try_lock (yes, I know it is try_scoped_lock, I am just lazy) and timed_lock being refinements of scoped_lock are incorrect. At best scoped_lock and try_lock are refinements of timed_lock as scoped_lock is timed_lock with time=infinite and try_lock is timed_lock with time=0. Therefore, we you insist on common lock functionality, it has to be encapsulated in one timed_lock (or maybe some basic_lock or just a lock). Then, all locks would refine that common behavior. That approach has the advantage of covering the case when I do not know what I want :-) -- then I'd simply use the basic_lock. 3. However, I personally feel that our attempts of generalizing locks are misguided. Locks are different, serve different purposes and provide different and distinct functionality. I feel that we should make an effort to keep different locks different and lean. Like try_lock actually tries to lock. Adding blocking (lock()) functionality to such a lock looks like a mistake as IMHO it encourages bad programming style as it allows to use try_lock where scoped_lock is needed. I feel that the situation when I do not know what kind of lock I need when I step into a function shows that the function needs to be-restructured/split so that in every new component I do know what I need. V.

3 2

Boost.Threads proposed change: lock constructors
by Michael Glassford 30 Jun '04

30 Jun '04

Below I detail proposed changes to the Boost.Threads lock class constructors. Comments? Questions? Mike ----------------------------------------------------------------- The Boost.Threads lock concept constructors are currently defined as follows: Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (type bool, true=locked, false=unlocked) Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s) //Blocking lock if s L l(m) //Non-blocking lock TimedLock Concept ----------------- L l(m,s) //Blocking lock if s L l(m,t) //Blocking lock, failing if not obtained by time t These definitions have the following drawbacks: 1) That one of the TryLock constructors blocks while the other doesn't is neither obvious nor very consistent. 2) That the single-parameter constructor of Lock blocks while the single-parameter constructor of TryLock doesn't is neither obvious nor very consistent. 3) Part of the reason for the above inconsistencies is that it's not clear whether the constructors of TryLock should block or not. 4) The TimedLock constructors have no way to request a non-blocking lock. To address these problems, I would like to redefine the lock concept constructors as follows (changes indicated with "^"): Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,b) //Lock; blocking if b ^ ^^^^^^^^^^^^^ TimedLock Concept ----------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,t) //Blocking lock, failing if not obtained by time t Note: s and b are defined as enums rather than bools to prevent existing code from breaking silently: e.g., if s and b were bools, "TryLock l(m, false)", which currently means "construct a lock object but don't obtain a lock", would change with the new definitions to mean "construct a lock and make a non-blocking attempt to obtain a lock". Also, enums are more explicit than bools. Note: these changes will cause some existing code to break by producing compile errors; the compile errors can be fixed by appropriately adding or changing parameters being passed to the changed TryLock and TimedLock constructors. Mike

4 10

[1.32 release] Boost.Test plan
by Rozental, Gennadiy 30 Jun '04

30 Jun '04

I plan to add one more big feature and several small one into this release. I should be able to finish all of this within 3 weeks. I mostly worry about some regression on old compilers. I will try to address most of it before committing. Gennadiy.

8 14

two thread libs? [was: Re: [boost] Re: logging library]
by John Torjo 30 Jun '04

30 Jun '04

> [snip] > Static-link build option added > > The option to link Boost.Threads as a static library has been added back with some limitations. This feature was originally removed because boost::thread_specific_ptr required that Boost.Threads be dynamically linked in order for its cleanup functionality to work on Win32 platforms. Several options are currently being explored to resolve this issue. In the meantime, the ability to link Boost.Threads statically has been added back with boost::thread_specific_ptr support removed from the statically linked version. The decision to add it back was made because its lack is one of the most frequent complaints about Boost.Threads and because the other approaches that are being investigated to deal with boost::thread_specific_ptr cleanup look fairly promising. so if I get the latest boost.thread I'll have all this (ability to use it as a static lib)? > > Note > Boost.Threads is still dynamically linked by default. In order to force it to be statically linked, it is necessary to #define BOOST_THREAD_USE_LIB before any of the Boost.Threads header files are #included. I'm not sure this is ok with me. I think it should still be statically linked by default (see below). > > Note > If the boost::thread_specific_ptr cleanup issue cannot be resolved by some other means, it is highly likely that the option to statically link Boost.Threads will be removed again in a future version of Boost, at least for Win32 platforms. This is because the boost::thread_specific_ptr functionality will be increasingly used by Boost.Threads itself, so that proper cleanup will become essential in future versions of Boost.Threads. Again, I don't understand why you need thread_specific_ptr within boost.threads so much. Anyway, if you need thread_specific_ptr so much, maybe we could do away with two libraries, something like: 'thread' and 'thread_ext' or so. In the thread, we should keep what was roughly before: - mutexes (don't tell me they need TLS) and scoped locks - thread class (no cleanup support) - xtime In the thread_ext, include whatever needs thread_specific_ptr, and extra goodies - this will have the statically/dynamically linked issue. I think this would be quite good in the long run, since there are so many libs/applications that only need basic thread support, and who really don't want an extra DLL added to the maintenance list. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

1 0

[1.32 Plan] multi_index
by Joaquín Mª López Muñoz 30 Jun '04

30 Jun '04

This is the plan for release of Boost.MultiIndex. This is a newly added library. Current status: commited in the CVS since 6 weeks or so. Regression tests are OK for all the compilers that I intend to support. If someone is interested in some other compiler being supported, please contact me. Pending issues: #1 Minor updates to the docs. No big deal. #2 Some changes related to the new defect macro BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS These issues will be resolved way before the branching date, I hope. Questions: #1 Dave talked about Aleksey going to merge a new version of MPL in the main trunk. When will that happen? How disruptive do you expect it to be wrt to the rest of libraries? #2 Should I update the additional stuff right away (links in the main and libraries pages, uploading of bio and picture etc.)? Or is anybody else taking care of that stuff? #3 Vladimir just talked about "adding markup for the failures". What is this? Is this something required as part of the regression fixing process? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

Explicit markup notes
by Aleksey Gurtovoy 30 Jun '04

30 Jun '04

Could I ask that every time we are adding an explicit failure to "status\explicit-failures-markup.xml" or, even more so, marking up a library as unusable, we also provide a note explaining the markup? We don't have to come up with a specific wording for every single failure -- there are a few standard notes at the end of the document that fit many common situations, and can be simply referenced by their ID (e.g. <note refid="3"/>), but not saying anything at all significantly defeats reports' usefullness. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Library doc link is broken
by Jeff Garland 30 Jun '04

30 Jun '04

The current CVS doc link seems to have gone down... Not Found The requested URL /regression-logs/cs-win32_metacomm/doc/html/libraries.html was not found on this server. Jeff

2 1

[Formal review result] Tribool
by Thomas Witt 30 Jun '04

30 Jun '04

Hi, I am happy to report that the "Tribool" library by Doug Gregor has been ACCEPTED into boost. Other than this there is very little to be said. Reviews were generally in favour of the library and the issues surfaced during the review have been addressed by Doug. There were some comments regarding the scope of the library. While I agree that an broader coverage of 3-valued logic might be good to have, I do not think it justifies delaying acceptance of the library. Regards Thomas Review Manager Tribool -- Thomas Witt witt(a)acm.org

1 0

Bug in token_functions.hpp
by Joe Gottman 30 Jun '04

30 Jun '04

I have found a bug in token_functions.hpp. I have a hello-world program that looks like this: ----------begin file #include <boost/token_functions.hpp> int main(int argc, char* argv[]) { boost::char_separator<char> sep; printf("Hello World!\n"); return 0; } ----------end file It fails under MSVC 6.0 with the following error messages: c:\jobs\boost\token_functions.hpp(261) : error C2065: 'is_pointer' : undeclared identifier c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(261) : error C2275: 'Iterator' : illegal use of this type as an expression c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(261) : error C2059: syntax error : ',' c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(264) : error C2238: unexpected token(s) preceding ';' c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(266) : error C2653: 'cat' : is not a class or namespace name c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled I believe the problem is that we need to add the line #include <boost/type_traits/is_pointer.hp> to token_functions.hpp. If I add this line to my program before including token_functions.hpp, everything compiles fine. Joe Gottman

1 0

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Hurd, Matthew 29 Jun '04

29 Jun '04

> Behalf Of Batov, Vladimir > > > bool foo(bool threadsafe) > > { > > mutex::scoped_lock l(m, !threadsafe); > > } > > I am not sure if the example above is appropriate and indicative of the > problem we are trying to solve. Thread-safety should not be a run-time > configurable property. Like we do not decide on the fly (at run-time) if > our ref.-counting class is to be thread-safe or not. All that is > resolved at compile time. >" Thread-safety should not be a run-time configurable property." I think this is somewhat incorrect as absolutes usually are. I currently have a design where I use both an interface that supports locking and an interface which does not. It is an important feature of the design. Using such a run time parameter is not my choice because I am especially sensitive to performance but it might be a better design for others given other requirements. Non-locking versions are also useful when you want to combine operations. Take a lock, do stuff, and then release lock. Repeatedly locking has deficiencies which may or may not matter to you. $0.005, Matt Hurd. FWIW I wrap boost mutexex and locks in my own policy-like stuff. E.g: ___________________________________________________________ struct shareable { protected: struct adapted_mutex : public boost::rw_mutex { adapted_mutex( lock_priority::type lp = lock_priority::exclusive ) : rw_mutex( convert( lp) ) {} ~adapted_mutex() {} }; struct adapted_try_mutex : public boost::try_rw_mutex { adapted_try_mutex( lock_priority::type lp = lock_priority::exclusive ) : try_rw_mutex( convert( lp) ) {} ~adapted_try_mutex() {} }; struct adapted_timed_mutex : public boost::timed_rw_mutex { adapted_timed_mutex( lock_priority::type lp = lock_priority::exclusive ) : timed_rw_mutex( convert( lp) ) {} ~adapted_timed_mutex() {} }; public: typedef adapted_mutex mutex; typedef adapted_try_mutex try_mutex; typedef adapted_timed_mutex timed_mutex; typedef shareable_lock<mutex> lock; typedef shareable_lock<try_mutex> try_lock; typedef shareable_lock<timed_mutex> timed_lock; typedef atomic_op_interlocked atomic_op; }; ___________________________________________________________ So I can parameterise classes with a synch policy. (Less than ideal but I haven't got around to making it nicer yet.) For the interface where I need to support single threaded and multi-threaded usage of the same object ( as opposed to type ) I use this approach... ___________________________________________________________ template < class S = synch::shareable > class instrument : public synch::monitor<S> { SYNCH_SIMPLE_ATTRIBUTE( susquehanna_code, std::string ); SYNCH_SIMPLE_ATTRIBUTE( exchange_code, std::string ); SYNCH_SIMPLE_ATTRIBUTE( underlying, std::string ); SYNCH_SIMPLE_ATTRIBUTE( bid, double ); SYNCH_SIMPLE_ATTRIBUTE( bid_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( ask, double ); SYNCH_SIMPLE_ATTRIBUTE( ask_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( last, double ); SYNCH_SIMPLE_ATTRIBUTE( last_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( prior_settlement, double ); }; ___________________________________________________________ This way I can use an object in the following manner: ___________________________________________________________ te::instrument<> i_sample; i_sample.exchange_code<true>("hello"); // locking { te::instrument<>::lock lk( i_sample.guard() ); i_sample.exchange_code<false>("hello"); // non-locking } i_sample.exchange_code("hello"); // locking std::string hello = i_sample.exchange_code(); // locking hello = i_sample.exchange_code<false>(); // non-locking hello = i_sample.exchange_code<true>(); // locking hello = i_sample.exchange_code_ref(); // non-locking by nature ___________________________________________________________ I could also specify te::instrument< synch::no_synch > // locking is elided te::instrument< synch::simple > // exclusive locking te::instrument< synch::no_synch > // allows recursive locking te::instrument< synch::shareable > // allows shared or exclusive locks (think r/w) The interface to the non-locking version is still valid. User must code to shareable concept for everything to work for all concepts. Where SYNCH_SIMPLE_ATTRIBUTE defines a bunch of simple attribute helpers and looks like: #define SYNCH_SIMPLE_ATTRIBUTE( VAR_NAME, VAR_TYPE ) \ \ public: \ template< bool > \ void \ VAR_NAME \ ( \ boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME \ ) \ { \ if ( boost::needs_lock<VAR_TYPE>::value ) { \ lock lk(guard_ ); \ VAR_NAME<false>( new_ ## VAR_NAME); \ } else { \ VAR_NAME<false>( new_ ## VAR_NAME); \ } \ } \ \ void \ VAR_NAME \ ( \ boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME \ ) \ { \ VAR_NAME < true > ( new_ ## VAR_NAME ); \ } \ \ template< > \ void \ VAR_NAME<false> \ ( \ boost::call_traits<VAR_TYPE>::param_type new_ ## VAR_NAME \ ) \ { \ VAR_NAME ## _ = new_ ## VAR_NAME; \ } \ \ template< bool > \ VAR_TYPE \ VAR_NAME( ) const \ { \ if ( boost::needs_lock< VAR_TYPE >::value ) { \ lock lk(guard_, synch::lock_status::shared ); \ return VAR_NAME<false>( ); \ } else { \ return VAR_NAME<false>( ); \ } \ } \ \ VAR_TYPE \ VAR_NAME( ) const \ { \ return VAR_NAME<true>( ); \ } \ \ template< > \ VAR_TYPE \ VAR_NAME <false>() const \ { \ return VAR_NAME ## _; \ } \ \ boost::call_traits<VAR_TYPE>::const_reference \ VAR_NAME ## _ref( ) const \ { \ return VAR_NAME ## _; \ } \ \ private: \ VAR_TYPE VAR_NAME ## _; \ SYNCH_SIMPLE_ATTRIBUTE includes an extra thing boost::needs_lock<VAR_TYPE>::value that checks if the size of the type is > pointer size which means, for Intel & AMD, that locking is not required as the assignment of aligned types is atomic. Copy constructors, assignment and cloning are further issues ;-) IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Proposal: signed.hpp
by Jeffrey C. Jacobs 29 Jun '04

29 Jun '04

Based on Dave Abrahams' recent notes, may I suggest the following draft for revision? http://starship.python.net/crew/timehorse/signed.hpp Thanks! Jeffrey

2 1

ReL[boost] Re: 1.32 release preparation
by Robert Ramey 29 Jun '04

29 Jun '04

David Abrahams <dave(a)boost-consulting.com> writes: >> Robert, I'm very happy to have your contributions in this discussion, >> but it's hard to take your diagnosis of where the problem lies all >> that seriously when you haven't even been through a single Boost >> release with a library of your own! >I hope I didn't squash the discussion with this remark; I'm really >interested in exploring the possibilities here. I guess I should've >asked how you formed your impressions of the problem's cause. As I recall, the previous release was scheduled for beginning November. I was working on the serialization library at the time and using the development tree at the time. When the release was announced, lots of new stuff was added. There were a couple of tweaks in the new iterators which required changes for me to keep up. Trying to develop new stuff based on he development tree became inconvenient but I needed features not it 1.30 . Then about the middle of January "is_abstract" was dropped in. This was an evolved version of one I had adapted from ?R Sharoni's code. It was slightly different from the original in the way compilers not supported. So we didn't have real good knowledge about which platforms supported it and what value it should return on platforms that didn't support it. I was considered a very small change but consumed maybe a week of back and forth. It became clear that I could not submit a proposed serialization library based on the development tree that could be reviewed by large number of members downloading the library over an extended period without users encountering a lot of frustration and my trying to keep up with a morphing main trunk. As soon as it was released, I switched to maintain compatibility with the released 1.31 and it has worked out well. Based on this experience, it is my perception that the main development trunk was at least somewhat fluid over a period of 2 to 3 months and this made development more difficult. These are just the things I happen to run into first hand. The traffic on the list left me with the impression that my experience wasn't unique. That is how I formed my impression of the problem's cause. It is my reluctance to contribute to this problem which has discouraged me from checking in the serialization library until it is at a point where I believe there are no undocumented bugs/deficiencies. That is why the serialization library is not yet checked in. At this point nothing in boost depends on the serialization library. Should that change in the future, this discussion convinces me that before checking in any non-trivial changes, I should re-run the whole test suite on my local setup. In the case of MPL, I would think that it would be prudent to run that part of the test suite that depends upon MPL on one's local environment before checking it in - given that we don't use a branch for untested code. Robert Ramey

2 1

1.32 release preparation
by Aleksey Gurtovoy 29 Jun '04

29 Jun '04

Hi All, I'm finally ready to start working towards the next release, which as some of you might remember I volunteered to manage. Below is a preliminary schedule what I would like to propose, subject to adjustments as I receive your input: June 24-27: Announce a preliminary release schedule, collect information about everyone's plans for the release, adjust/confirm the schedule, make regression reports to reflect the actual status of the main trunk, setup nighly runs of the inspection report (http://tinyurl.com/2vo5p) construct a "Release Progress" page publishing the milestones, the collective TODO list, and links to all the reports. June 27-July 16: Use regression reports to identify and resolve the outstanding issues with the main trunk. Walk through and deal with all the patches and bug reports submitted to the list/SourceForge tracker since the last release. In accordance with the TODO list, track the progress of individual developers. By July 15, 24:00 US Central Time every line of code that is intended to be put into this release should be in the CVS, and the next round of regression reports should show no regressions against the then-current expected failures markup. July 16: Branch for release. Switch regression tests to run on the branch. July 17-July 18: No code checkins are allowed expect to fix the failures resulted from branching (hopefully none). Documentation checkins are still OK. Perform the rest of the pre-release tasks listed in http://tinyurl.com/2meuh. July 18, 24:00 US Central Time marks a complete freeze of the branch. July 19-July 20: Prepare and test the release candidate archives. Fix any found issues and repeat. July 21: Release according to the http://tinyurl.com/2meuh procedure. As you can see from the first milestone's description, at this point I'd like to collect everybody's plans for the release (for those developers who do plan to do something, of cource), with approximate dates, so that we have a better understanding of how everything is going to fall together. Please post these plans to the list with "[1.32 Plan]" prefix in the subject. As usual, any other comments/suggestions are more than welcome. Thank you! -- Aleksey Gurtovoy MetaCommunications Engineering

14 29

typo in boost::thread
by Janusz Piwowarski 29 Jun '04

29 Jun '04

Hello, Numerous files of boost::thread has CR+CR+LF as line ending. I noticed it happens regularly, maybe there's a way to prevent this? Also, there's a typo in try_lock member of scoped_timed_lock<TimedMutex> class: is: return (m_locked = lock_ops<TryMutex>::trylock(m_mutex)); should be:? return (m_locked = lock_ops<TimedMutex>::trylock(m_mutex)); Regards, Janusz

2 2

RE: [boost] The Test Tools Docs, Concept Checking
by Rozental, Gennadiy 29 Jun '04

29 Jun '04

I could add proposed text, once somebody prepared it. Gennadiy. > Hi, > > I have been reading the Test Tools docs. Would it be a > good idea to add ConceptChecking to the list of alternative > methods of reporting errors, in > /test/doc/index.html#introduction ? A recent post on boost > alluded to the fact that Concepts (ie What is a concept? ) > can be difficult to understand. Well ... ConceptChecks are > the medium for pinning down Concepts in C++ code and are > probably the most effective means of error reporting at > compile time, but are not used as much as they could be. The > Boost Test Library would seem to be as good a place as any to > promote them, which could help to remove some of the mystery. > > regards > Andy Little

3 2

[Test] Failures on GCC 2.95.3
by Doug Gregor 29 Jun '04

29 Jun '04

The file boost/test/detail/basic_cstring/io.hpp contains this workaround function for GCC 2.95.3: template<typename CharT> inline std::ostream& operator<<( std::ostream& os, basic_cstring<CharT> const& str ) { typedef typename basic_cstring<CharT>::mutable_char char_type; char_type const* const beg = reinterpret_cast<char_type const* const>( str.b egin() ); char_type const* const end = reinterpret_cast<char_type const* const>( str.e nd() ); os << std::basic_string<char_type>( beg, end - beg ); return os; } What is mutable_char? It doesn't show up anywhere else in Boost. Doug

2 1

Missing http://www.boost.org/regression-logs/cs-win32_metacomm/developer/index.html
by Doug Gregor 29 Jun '04

29 Jun '04

I have a sinking feeling that I might have broken something when modifying the explicit failures file :( Doug

2 1

Re: Boost.Threads proposed change: lock constructors
by Batov, Vladimir 28 Jun '04

28 Jun '04

> Part of the point, though, is that try_lock doesn't actually work that > way: one of the try_lock constructors does a non-blocking try_lock(), > and the other does a blocking lock(). Without looking, do you always > remember which one does which? I don't. Well, first, the behavior that I was talking about in my prev. email (ones I was happy about) were the 'basic' constructors (that I called 'default' constructors -- what an embarassment). The following is IMHO good and I would not like see them complicated: 1. scoped_lock l(m); // Blocks until it locks. 2. scoped_lock l(m, true); // As above. 3. scoped_lock l(m, false); // Only declaration. Does nothing. Needed if I need to declare but use it later. 4. try_lock l(m); // Tries to lock. Always falls through. I need to check the result. 5. try_lock l(m, false); // Only declaration. Does nothing. 6. timed_lock l(m, time); // Blocks until locks or 'time' expires. 7. timed_lock l(m, false); // Only declaration. Does nothing. I have to agree that the following behavior 8. try_lock l(m, true); 9. timed_lock l(m, true); that according to the documentation call lock() instead of respective try_lock() and timed_lock() look wrong. I'd be temted to say that merely making (8) work as (4) would be sufficient fo fix try_lock. (9) does not appear "fixable" in a similar way. I am tempted to suggest something similar to overloaded 'operator new': struct nolock_t {}; nolock_t nolock; 1. scoped_lock l(m); 2. scoped_lock l(m, nolock); 3. try_lock l(m); 4. try_lock l(m, nolock); 5. timed_lock l(m, time); 6. timed_lock l(m, nolock); It removes redundancy (as with the original scoped_lock(m) and scoped_lock(m, true)) and makes everything simple and consistent. Just a thought. V

2 1

How to handle name mangling in "versioned" toolsets?
by John Maddock 28 Jun '04

28 Jun '04

At present we have two types of toolsets: 1) Unversioned toolsets such as "intel-win32", which produce unversioned toolset suffixes to library names, "iw" in this case. 2) Versioned toolsets such as "intel-win32-7.1-vc6-stlport-4.5.3" which produce versioned toolset suffixes to library names, "iw71" in this case. This produces a problem with the autolinking code which can take either approach, but not both (or at least not both auto-magically, and this is causing some regression test failures at present). In other words I'm asking for some kind of consistent policy here; note that if the choice is to consistently use "versioned" toolsets then we're committing ourselves to constantly updating the build system and autolinking code to keep up with new compiler releases. So, I guess I'm leaning towards "unversioned" mangled toolset names, but would like more some feedback, so: what does everyone else think? Thanks, John.

3 2

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 28 Jun '04

28 Jun '04

My question was more about the design rather than how I could work it around. I may be wrong but specializing mutex does not look like a good idea as it appears to be lock-specific functionality. So, I thought we might consider having only mutex and typedefing others to it (not to break old code) -- the simpler the better. Isn't it? V. > Do we need all three separate concepts -- mutex, try_mutex and > timed_mutex? I think the idea was that it would be possible to implement the mutex types that supported fewer operations more efficiently. Whether this actually turned out to be true is another question. > I'd expect the mutex concept to remain unchanged and "try" > and "timed" refinements to be related solely to the ways I try locking > that only mutex. That is, I always have one mutex and under different > circumstances lock it unconditionally (scoped_lock) or try locking it > and check if that attempt succeeds (scoped_try_lock) or try locking > within a certain time period (scoped_timed_lock). If you want this, just use a timed_mutex and scoped_timed_lock. In the current release it supports lock() and timed_lock() operations; in the next release it will support try_lock() as well. Mike ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 772, Issue 2 *************************************

1 0

GCC 3.4 lpthread warnings
by Jeff Garland 28 Jun '04

28 Jun '04

On the regression tests I'm seeing lots of warnings from gcc 3.4. For example: date_time - test_greg_wstream - gcc-3.4.0-linux Compiler output: In file included from /boost/head-regression/boost/boost/config.hpp:44, from /boost/head-regression/boost/boost/date_time/locale_config.hpp:19, from /boost/head-regression/boost/boost/date_time/compiler_config.hpp:14, from /boost/head-regression/boost/boost/date_time/gregorian/gregorian.hpp:19, from ../libs/date_time/test/gregorian/testgreg_wstream.cpp:10: /boost/head-regression/boost/boost/config/stdlib/libstdcpp3.hpp:33:7: warning: #warning "Boost threading support turned on, you may need to link against -lpthread unless you define BOOST_DISABLE_THREADS when building." Lots of other libraries are seeing similar warnings with gcc 3.4. Date-time does nothing with threads so I believe based that I should just set define BOOST_DISABLE_THREADS for the test cases to resolve this. But since I'm not certain of all the implications of this I thought I'd as for advice before proceeding. One specific question that comes to mind is do I need to limit the scope to gcc so I don't break MT, dll mode on Windows? Thanks, Jeff

6 15

[admin] Wiki Spam -- IP's are being banned
by Jeff Garland 28 Jun '04

28 Jun '04

All - I'm cross-posting this to boost-users and the developer list since it pertains to both. Over the last couple months there has been a rise in 'spam attacks' on the Wiki. Basically people are inserting links to commercial sites on wiki pages. These sites are totally unrelated to boost, c++, etc. I thank the many boosters that have spent their precious time removing the defacements. But the time has come to crack down. The following IP ranges have been banned from the Wiki. 61.55.32.* 61.55.33.* 69.63.103.* 210.82.76.* 210.82.106.* 219.233.195.* 218.5.65.* I will be monitoring and banning additional IP addresses as needed. If I have accidentally banned someone incorrectly, please let me know offlist: jeff at crystalclearsoftware.com Thanks, Jeff

1 0

shared_ptr<> and atomic_count
by Colin Rafferty 28 Jun '04

28 Jun '04

Hi- Looking at the implementation of shared_count<>, it seems as though it always uses a mutex for incrementing and decrementing the counter. Is there a reason why we aren't using atomic_count instead? In the worst case, it will have the same performance, but in the best case, it can be significantly faster (BOOST_USE_ASM_ATOMIC_H). Thanks. -- Colin Rafferty

1 0

Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Mon, 28 Jun 2004 07:37:24 -0400, David Abrahams wrote > Boost.Graph changes have caused plenty of regressions in Boost.Python > in the past. Sorry, I thougth that this would be a pretty good example of a high level library. So I was wrong. On Mon, 28 Jun 2004 07:33:26 -0400, David Abrahams wrote > We should have more releases. Waiting for libraries to be checked in > is one thing that keeps us from being able to release more frequently. Yes, but if I have the choice of waiting one additional week for the check in of an accepted library against waiting 2 month for the next release I would choose to wait that additional week. However, I have read in one of the other mails that you have a deadline with your book. So live is not that simple at all. I won't persist on changing the planned schedule. Don't get me wrong. > It sounds like you want a whole new Boost procedure for reviews *and* > releases. That seems like a stretch; we don't have any idea whether > it would work at all. No, I merely think that a library should be accepted when it is ready for checkin and there is not a list of changes and request pending. On Mon, 28 Jun 2004 07:34:22 -0400, David Abrahams wrote >> On Mon, 28 Jun 2004 10:51:36 +0200, Johannes Brunen wrotes >> We should list them on the lib page but in a special section. > I don't like the sound of that. It should be very clear to people > which things are part of Boost and which aren't. Ok, I second that. If it not clear for people what is part of boost then it is the wrong way. People should be able to build on a boost release. With kind regards Johannes

1 0

iterator_traits.pdf not marked as binary
by Peter Dimov 28 Jun '04

28 Jun '04

libs/iterator/doc/iterator_traits.pdf is not marked as binary in the CVS. -- Peter Dimov http://www.pdimov.com

2 1

[Graph] What to do about broken compilers?
by Doug Gregor 28 Jun '04

28 Jun '04

The graph library has always been in a "barely usable" support on certain compilers (Borland <= 5.6.4 and MSVC 6.0, in particular). The regression tests have always been a mess---Boost 1.31.0 has very few passes for these compilers, and 1.32.0 isn't looking any better. However, the library is somewhat usable, if you stick to a very small subset and don't mind working around INTERNAL COMPILER ERRORs all of the time. What to do? I'm marking the library "unusable" on both compilers, so that we can concentrate our efforts on those compilers that might actually work. Complain loudly, quickly, and preferably with patches if you think this is the wrong approach. Doug

4 5

Boost.Threads: RW mutexes and locks.
by Batov, Vladimir 28 Jun '04

28 Jun '04

RW mutexes/locks are important to a threading library and appear simple to implement. However, Boost.Threads lacks it. I wrote something simple that appear to do the job using the functionality already available in Boost.Threads. If the idea is considered good/robust/efficient enough and worth having in the library, I can re-write it to conform with the rest of Boost.Threads. class rw_mutex : private boost::noncopyable { typedef boost::condition Condition; public: friend class writer_lock; friend class reader_lock; rw_mutex() : num_readers_(0), num_writers_(0) {} private: boost::mutex mutex_; Condition reader_condition_; Condition writer_condition_; int num_readers_; int num_writers_; }; class writer_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: writer_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { ++mutex_.num_writers_; // Make new readers wait. // If there are readers in-progress, wait for them to finish. while (mutex_.num_readers_) mutex_.writer_condition_.wait(*this); } ~writer_lock() { --mutex_.num_writers_; // Last writer notifies waiting readers. // If not last, wake up the next writer. if (!mutex_.num_writers_) mutex_.reader_condition_.notify_all(); else mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; }; class reader_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: reader_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { // If there are writers waiting, let them in first. while (mutex_.num_writers_) mutex_.reader_condition_.wait(*this); ++mutex_.num_readers_; // Make new writes wait. unlock(); } ~reader_lock() { lock(); --mutex_.num_readers_; // Last reader notifies if (!mutex_.num_readers_) mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; };

3 2

Re:[boost] Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 19:05:45 -0700, Robert Ramey wrote > Here is the current scenario. > > a) The announcement gets posted - release 1.32 scheduled for date x. > b) Each developer decides - uh oh I better get in my changes before date x. > c) Of course these changes take longer > d) and break some other things > e) which takes longer still IMHO, point d) touches a weak point: There are two kind of libraries in a system like boost. At first, there are core libraries which are used by many other libraries. Changes at these libraries are potentially dangerous and must be well-considered since they can broke a lot of stuff. They should early checked into CVS to get time for stabelizing the base. Secondly, there are libraries which 'only' provide a special feature like the boost graph library the circular_buffer library. They shouldn't be expected to lead to regressions of other boost libraries. I think that they could be handled differently than the core libraries. > a) the release manager or the core influential developers keep an eye on the > current state of the CVS tree and tests. > b) When things look "pretty good", branch for release without warning. None > of this loading my latest feature in to make the schedule. > c) the Main tree goes on as usual > d) pending issues in the release branch are addressed by nagging the person > responsible. > e) the new version is releases with a number like 1.31.1 or maybe even 28 > July 2004. > f) any changes between branch and release should be just bug fixes which can > then be merged back into the development tree. > > Under this system, releases would occur more frequently - on the order of 6 > weeks. If you're ready to check in your latest feature and the new release > branch catches you with your pants down - well too bad. But it's no big deal > because the next release will be in 6? weeks anyhow which is close to what > its going to take to shake out the repercussions of your check in anyway. We should seriouly consider such a release process. Howerver, then the CVS main tree must always be in a nearly 'Release-Ready' state. But IMO that is anyway a good idea. > But I > think it's really hard to get such a large number of people working > independently on exactly the same schedule. Yes ... > Almost all libraries are accepted subject to some changes being made. Many > such changes seem simple but end up rippling through the whole library. This > takes time. This is IMHO an indication of a flaw in the current boost review process. A library should be only accepted after the list of requested changes has been made. Additionally, I think a library should be accepted only if it is compatible to the current CVS main tree. > Once a library is accepted, then one can get serious about making it pass > with a larger number of compilers. This also takes time - a lot of time Passing compilers which weren't supported during the review process under no circumstances shouldn't delay the integration of the library into the boost main pool. Supporting a special compiler is only a nice to have feature. This means not that it not worth spending the effort supporting important platforms. However, in the first iteration I just expect a library to be written in ANSI C++ and to be usable on platforms which support it. > These changes end up having a ripple effect and can result it changes like > moving things in namespaces and subdirectories. While this is going on, the > system is broken and really not suitable to be subject to the daily testing > routine. This is IMHO an indication of a flaw ... (s.a) > So it seems attractive to deal with all this stuff before one does > the initial check in to CVS. This way one can start with a relatively clean > start. I second this. With best regards Johannes

2 1

Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 16:35:15 -0400, David Abrahams wrote > Should we have accepted libraries checked in immediately (on a branch, > maybe?), Maybe we should reconsider the meaning of 'acceptance' in the review process. Apart of that, I think that this is a very good idea. > and then only added to the libs page when the authors > deem them ready? We should list them on the lib page but in a special section. > If they're checked in on the trunk they can even get the benefit of > regression testing while the authors whip them into shape. Yes, that would be fine. With best regards Johannes

2 1

Re: [boost] Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 08:30:20 -0700, Jeff Garland wrote: > As much as I'd like to see circular_buffer, serialization, etc in this release I'd rather > see us pull off a release that doesn't take 2-3 months to accomplish. I > believe we should hold the line on the schedule now and anything that isn't > ready should simply go in the next release. I disagree on that. We don't have that many Boost releases. Waiting for the next one could be a long time. Therefore, I propose to wait until all (or as many as possibly considering a reasonable time schedule) accepeted libraries will be checked into CVS and be part of the release. > And if there are a large > number of new things left out by that approach then we should plan another > release sooner rather than waiting 4 months. However, then you need new volunteers which have to spend the time for the whole procedure again. > One is that we have been reviewing and > accepting a large number of libraries recently. So, many of these have been > accepted in the last couple months. The other thing that seems to be a > pattern is that libraries get accepted, then authors get a list of changes to > make. I could think of a review process which accepts a library only after the list of requested changes has beem made. > If they get busy it often takes months to get these done and then > finally they check into CVS. So a release tends to trigger the evaluation of > anything that is in that multi-month pipeline. That isn't good. I would prefere a review process which leads to final acceptance only after a library is 'CVS' compatible i.e. does not yield to any (known) regressions of the existing pool libraries and is equipted with a working testing facility. With best regards Johannes

2 1

Re:[boost] Re: 1.32 release preparation
by Robert Ramey 28 Jun '04

28 Jun '04

Dave Abrahams wrote: >I'd like to know the reasons for "all the sudden rush". We did >announce a schedule long ago, and it has already been delayed by three >weeks. I'm not asking in order to point fingers; I just want to know >how to avoid the "sudden rush" next time. Here is the current scenario. a) The announcement gets posted - release 1.32 scheduled for date x. b) Each developer decides - uh oh I better get in my changes before date x. c) Of course these changes take longer d) and break some other things e) which takes longer still Personally I think the concept of scheduling a release fundamentally flawed. I would suggest another idea. a) the release manager or the core influential developers keep an eye on the current state of the CVS tree and tests. b) When things look "pretty good", branch for release without warning. None of this loading my latest feature in to make the schedule. c) the Main tree goes on as usual d) pending issues in the release branch are addressed by nagging the person responsible. e) the new version is releases with a number like 1.31.1 or maybe even 28 July 2004. f) any changes between branch and release should be just bug fixes which can then be merged back into the development tree. Under this system, releases would occur more frequently - on the order of 6 weeks. If you're ready to check in your latest feature and the new release branch catches you with your pants down - well too bad. But it's no big deal because the next release will be in 6? weeks anyhow which is close to what its going to take to shake out the repercussions of your check in anyway. I realize that this is not the most orthodox way of doing things. But I think it's really hard to get such a large number of people working independently on exactly the same schedule. >How come we have so many >accepted libraries that have not even been put in the CVS? Almost all libraries are accepted subject to some changes being made. Many such changes seem simple but end up rippling through the whole library. This takes time. Once a library is accepted, then one can get serious about making it pass with a larger number of compilers. This also takes time - a lot of time These changes end up having a ripple effect and can result it changes like moving things in namespaces and subdirectories. While this is going on, the system is broken and really not suitable to be subject to the daily testing routine. So it seems attractive to deal with all this stuff before one does the initial check in to CVS. This way one can start with a relatively clean start. Robert Ramey

6 6

Problems compiling regex with gcc3 on aix and hpux
by Goetz Isenmann 28 Jun '04

28 Jun '04

Hi! I get ugly warnings (they look dangerous to me) when I compile boost/regex on AIX and HP-UX with gcc. On Linux and FreeBSD everything is fine. For example /usr/local/gcc-3.3.3/bin/g++ -c -I. libs/regex/src/cregex.cpp compiles without any complains. On aix43 and hpux11 this gives me the attached warning messages. The order of the messages is slightly different on both platforms, but after sorting the output is identical. I use boost-1.31.0 and see no differences with and without boost-1.31.0-regex-patch-20040503. -- Goetz Isenmann

2 3

Provisional schedule for Boost-1.33
by John Maddock 28 Jun '04

28 Jun '04

Booster's: It's apparent that several of us will just miss the 1.32 deadlines, and I'm sure some people will be concerned when their code will get released as a result, so provisionally I'd like to propose a schedule for 1.33 so we all know where we are. Unless someone else would like to volunteer (and please don't be shy in doing so!), then I guess that means I've just volunteered to manage the release.... Regards, John Maddock. Provisional 1.33 release schedule: ~~~~~~~~~~~~~~~~~~~~~~ Mon 30th August 2004 [1]: ~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to known issues, and docs) to core Boost libraries [2]. Deadline for the addition of new libraries to cvs unless they pass all tests with the core compiler set [3]. Mon 13th September 2004: ~~~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to regressions, and docs) to all Boost libraries. Deadline for all new library additions. Mon 27th September 2004: ~~~~~~~~~~~~~~~~~~ Branch for release, no changes to the release branch without the release managers permission (except for docs). Mon 4th October 2004: ~~~~~~~~~~~~~~~~ First release candidate published, actual release will be as soon as possible thereafter. Notes: ~~~~ 1) There should be a few reminders of this deadline in the weeks beforehand. 2) The core Boost libraries are those that other Boost libraries heavily depend upon: bind config (unless change is restricted to a single compiler, and can be tested with all effected versions of that compiler before commit). enable_if. integer. iterators (the construction framework subset only). mpl operators preprocessor smart_ptr's static_assert test type_traits. 3) The core compiler set includes those compilers that are known to be highly conforming, and for which no failures will normally be expected: gcc 3.3 or later on Linux. Visual C++ 7.1 on Win32. Intel C++ 8 on Win32 or Linux.

1 0

Re: 1.32 release prepar
by Robert Ramey 28 Jun '04

28 Jun '04

Last time we ended up making a release candidate which isolated a couple of final issues. Maybe this is a symptom and maybe it points in the direction of an interesting idea. New code is checked in and tested in the development tree just as it is now. Regression testing and everything remains exactly as it is. Code that documents all test failures and is considered ready for release is moved to the Release Candidate tree. The exact same regression testing setup used on the development tree is used here. Presumably, it would be run much less as things would only be checked in when thought to be perfect which is an infrequent occurrence. Developers develop against the Release Candidate tree. When they have something they like, the check into the Main Development tree as they do now. Traffic on the main development tree is the same as it is now. The Release Candidate Tree should be ready for "shipment" at any convenient time. This basically should consist of assignation of a version number to the tree state. It would not be or scheduled event dramatic event. It could happen as frequently as is convenient. Of course a test failure on the RC tree would be dramatic event. The check in causing such an event could be cast from the RC Tree (Heaven) back into the Main Development Tree (Purgatory) and the author would suffer the attendant embarrassment. Hopefully this would be an infrequent event. I realize that I haven't personally had a library go through the release process so feel free to ignore this idea. Robert Ramey

2 1

[config] about BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS
by Joaquín Mª López Muñoz 28 Jun '04

28 Jun '04

In config/intel.hpp, this defect macro is defined as follows #if defined(__ICL) && (__ICL <= 710) # define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS #endif The macro should be defined *only* for Intel C++ 7.1 or older for Windows 32-bit. So my questions are: 1. Is the definition correct in light of what I said above? 2. What's the meaning of all those different macros __ICC, __ICL and __ECC? I've googled for them but found nothing conclusive. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

RE: Boost.Threads: RW mutexes and locks.
by Batov, Vladimir 28 Jun '04

28 Jun '04

John Torjo wrote: > Batov, Vladimir wrote: >> >> class writer_lock : public boost::mutex::scoped_lock >> { >> typedef boost::mutex::scoped_lock super; >> >> public: >> >> writer_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) >> { >> ++mutex_.num_writers_; // Make new readers wait. > ^^^^ > > just curios, shouldn't this be thread-safe? I believe it is thread-safe as writer_lock currently inherits from scoped_lock and, consequently, we get inside the writer_lock constructor after its base-class scoped_lock constructor. The base-class constructor does the synchronization.

1 0

store a boost::bind
by Nico Massi 27 Jun '04

27 Jun '04

Hi, Is it possible to store a boost::bind? boost::bind<int> x( f, _1, _2 ); int i = x( 3, 4 ); I get errors if i want to declare a variable of type boost::bind. The point is: I want to have an object that gets a boost::bind, stores it and executes it with the correct values to the time i want. How can i do this? Ciao

4 6

[1.32 Plan] Any date for new version of MPL
by JOAQUIN LOPEZ MU?Z 27 Jun '04

27 Jun '04

Any tentative date for the new version of MPL making it into the CVS? Specially if we stick to July 21st a the release date, I'm concerned that the new MPL will have us fixing regressions for quite a few weeks. OTOH, maybe the update is smooth enough and not many problems arise, but it'd be good to know. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

detail/atomic_count_gcc.hpp error
by Rene Jager 27 Jun '04

27 Jun '04

trying to do: boost::detail::atomic_count c(0); std::cout << long(c) << std::endl; with gcc 3.2.2 gives: /usr/include/boost/detail/atomic_count_gcc.hpp: In member function `boost::detail::atomic_count::operator long int() const': /usr/include/boost/detail/atomic_count_gcc.hpp:46: invalid conversion from ` const _Atomic_word*' to `volatile _Atomic_word*' in the following function: operator long() const { return __exchange_and_add(&value_, 0); } The problem can be solved by making the private member "_Atomic_word value_" mutable. renej ps I know I shouldn't use detail/* stuff directly... --

3 3

[Concept checking] Missing TrivialIteratorConcept
by Hervé Brönnimann 27 Jun '04

27 Jun '04

Hi just occured to Sylvain Pion and myself recently that the TrivialIteratorConcept is documented but not part of the code, and same for Mutable_TrivialIteratorConcept. It is also missing from the test suite (concept_check_test.cpp) and from the archetypes. This may be intentional or not, but probably either the concepts and archetypes should be added to the code, or removed from the documentation. A small and easy bugfix for 1.32? -- Herve'

2 1

A new way of sorting and searching
by Nic Roets 27 Jun '04

27 Jun '04

Often when I write searching or sorting code in C or C++, I'm frustrated that I have to make a new "callback type" compare function. E.g. when you want to sort a number of points in 2D space according to their distance from a reference point, it's tempting to do something like struct Pt { int x, y; }; static Pt center; // Global or static variable yuck. int PtDistToCenterCmp (Pt &a, Pt &b) { return Dist (a, center) - Dist (b, center); } main() { ... center.x = ...; center.y = ...; ... sort (...); ... } This type of solution has many problems. Reviewing the code for correctness is difficult because now you have to read half way through main, stop to find the definition of center, then continue with main, then find the definition of PtDistToCenterCmp, then continue with main. To solve this problem I suggest a new template class "sorter" : template<class t> struct sorter { // Qsort would require a stack here. Heapsort only a few variables. iterator a, b; sorter(iterator begin, iterator end); // Exuse my cpp if it's // incorrect int Operate (int cmpResult); }; Then it would be used like this : void main () { ... sorter<Pt> sortObj (..., ...); while (sortObj.Operate ( Dist (sortObj.a, center) - Dist (sortObj.b, center))) {} ... } IMHO this is much clearer. A binary searching template class can also be implemented in this way. -- Regards Nic Roets

3 2

Request for reviewers for a CUJ article
by Joaquín Mª López Muñoz 27 Jun '04

27 Jun '04

I've just finished an article for publication in CUJ about Boost.MultiIndex (they accepted the preliminary proposal.) The author guidelines suggest that a couple of technical peers do a review of the text before submission (specifically, the purpose is that the peers "can give you candid feedback regarding accuracy and adherence to standard industry practices".) So, I kindly request some volunteer wanting to do the job. The review shouldn't be too time-consuming (about 3,000 words of text.) I guess someone without prior exposure to the library is a better candidate, so as to probe the introductory quality of the article. Due to (c) issues I guess I cannot just put the article on the web for you to download. If you are interested, please contact me privately and I'll send you the text. Thanks very much for your help. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Re:BOOST_STATIC_ASSERT(false) - was (no subject)
by Robert Ramey 27 Jun '04

27 Jun '04

I hadn't considered Michaels idea. I've been using BOOST_STATIC_ASSERT(0 == sizeof(T)). Michiel Salters wrote: >Robert Ramey wrote: >> BOOST_STATIC_ASSERT(false) >This *should* work. IMHO, if it doesn't, we should fix it, not work >around it like Michiel suggested. I don't think I'ts fixable. But maybe one might want to make another macro named something like BOOST_BETTER_NOT_ARRIVE_HERE - lol >> However, its doesn't work >> with compilers that are too smart for their own good. In order to make this >> work I need something like: >Which compiler and which version of boost and the Compiler are you >using? Can you provide a minimal but complete example? Also, you might >want to have a look at checked_delete where we had similar problems in >the past IIRC. I've noticed it at least on Comeau. I just used the fix above so now I don't see it. So now I don't know which compilers complain. Robert Ramey

2 1

newbie question: Cannot open include file: 'boost/filesystem/operations.hpp': No such file or directory
by Chris 27 Jun '04

27 Jun '04

Hi to all.. sorry for the newbie question. I believe I have built the Boost libs correctly. I used: bjam -s"TOOLS=vc7.1" -s"VC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7" install The Includes and Libs are in C:\Boost as described in the "Getting Started Guide" Also I didn't get any errors during the building process (that's why I assume the build was succesfull), so I decided to test the libraries and just took one of the examples form the site. Compiled it and got the: "fatal error C1083: Cannot open include file: 'boost/filesystem/operations.hpp': No such file or directory" #include "boost/filesystem/operations.hpp" #include "boost/filesystem/path.hpp" #include <iostream> namespace fs = boost::filesystem; int main( int argc, char* argv[] ) { //removed for brevity... } I also added the path to the environmental variables in windows, under INCLUDE and LIB, but this didn't seem to change anything. Can anyone help me understand why the compiler doesn't find the headers? What am I missing? Thank you in advance for your help... Chris PS. I am really sorry for the newbie question....

2 1

Problems with conditions in boost::thread
by Andreas Pokorny 27 Jun '04

27 Jun '04

Hi, I just started to use boost::thread in a bigger application. Since the condition variables do not work as expected - e.g. the waiting thread never wakes up ( example can be found here: http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/xeta/curl.cpp ) - I started writing a smaller test case to see if I use the library correctly. That little test application works fine if I run it in with the gnu debugger, and if I have debugging symbols in my glibc. In all other cases the process gets terminated before any debuging print outs show up or the debugger fails to run the application: #include <list> #include <iostream> #include <boost/bind.hpp> #include <boost/thread/xtime.hpp> #include <boost/thread/thread.hpp> using namespace boost; struct Mini { bool running; thread worker; mutex list_mutex; condition items_empty; std::list<std::string> items; typedef mutex::scoped_lock lock; Mini(); ~Mini(); void run(); void add( std::string const& item); }; Mini::Mini() : worker( bind( &Mini::run, this ) ) { } Mini::~Mini() { running = false; { lock the_list( list_mutex ); items_empty.notify_one(); } worker.join(); } void Mini::run() { running = true; while( running ) { lock the_list( list_mutex ); if( running && items.empty() ) { std::cout << "Waiting for item" << std::endl; items_empty.wait( the_list ); std::cout << "Continue" << std::endl; } std::cout << "Removing :" << items.front() << std::endl; items.pop_front(); } } void Mini::add( std::string const& item ) { lock list_access( list_mutex ); std::cout << "Adding :" << item << std::endl; items.push_back( item ); std::cout << "Notifying other thread" << std::endl; items_empty.notify_one(); } int main() { Mini my_mini; my_mini.add("Once upon a time"); my_mini.add("there was a little mouse"); my_mini.add("that lived in a little house"); xtime xt; xtime_get(&xt, TIME_UTC); xt.sec += 2; thread::sleep(xt); } After that I tried to do it without boost. This time everything works as expected, with and without debugger. #include <list> #include <unistd.h> #include <iostream> #include <pthread.h> struct Mini { bool running; pthread_t worker; pthread_mutex_t mutex; pthread_cond_t not_empty; std::list<std::string> items; Mini(); ~Mini(); static void * call_run( void *); void run(); void add( std::string const& item); }; void* Mini::call_run( void * ptr) { static_cast<Mini*>(ptr)->run(); return 0; } Mini::Mini() { pthread_mutex_t temp_mut = PTHREAD_MUTEX_INITIALIZER; mutex = temp_mut; pthread_cond_t temp_cond = PTHREAD_COND_INITIALIZER; not_empty = temp_cond; worker = pthread_create( &worker, 0, Mini::call_run, this ); } Mini::~Mini() { running = false; { pthread_mutex_lock( &mutex ); pthread_cond_broadcast( &not_empty ); pthread_mutex_unlock( &mutex ); } pthread_join( worker, 0 ); pthread_cond_destroy( &not_empty ); } void Mini::run() { running = true; while( running ) { pthread_mutex_lock( & mutex ); if( running && items.empty() ) { std::cout << "Waiting for item" << std::endl; pthread_cond_wait(&not_empty, &mutex); std::cout << "Continue" << std::endl; } std::cout << "Removing :" << items.front() << std::endl; items.pop_front(); pthread_mutex_unlock( &mutex ); } } void Mini::add( std::string const& item ) { pthread_mutex_lock( & mutex ); std::cout << "Adding :" << item << std::endl; items.push_back( item ); std::cout << "Notifying other thread" << std::endl; pthread_cond_broadcast(& not_empty); pthread_mutex_unlock( &mutex ); } int main() { Mini my_mini; my_mini.add("Once upon a time"); my_mini.add("there was a little mouse"); my_mini.add("that lived in a little house"); sleep(2 ); } Any ideas?

2 2

Autolinking problem on Intel (Win32) with STLport
by Doug Gregor 26 Jun '04

26 Jun '04

It looks like there is a problem with autolinking as mentioned in the subject. It looks like a library naming issue: http://tinyurl.com/2djmv Doug

2 2

How to use boost::thread::condition
by Andreas Pokorny 26 Jun '04

26 Jun '04

Hi, I have problems understanding how mutexes, scoped locks and conditions should work togehter. I took the condition.cpp example and with the buffered shared by two threads as a basis of my code: http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/xeta/curl.cpp There is a list filled by one thread, and a thread that removes the entries after they have been downloaded using curl. The worker-thread waits for a jobs_empty condition and the insertion method calls notify_one after every insertion. Currently the worker-thread just prints "Sitting and waiting", and never reacts on any calls of notifiy_one(). Regards Andreas Pokorny

1 1

BOOST_WORKAROUND in test files?
by Gennaro Prota 26 Jun '04

26 Jun '04

Hi, is it allowed/OK to use BOOST_WORKAROUND in the boost test files? Or should we simply use #if/#ifdef? For instance, Codewarrior 8.3 for Windows has some problems in parsing a function template in dyn_bitset_unit_tests4.cpp. A simple fix, suggested by Howard, is: #ifdef __MWERKS__ // will be: __MWERKS__ && __MWERKS__ <= xxx #pragma parse_func_templ off #endif Should this use BOOST_WORKAROUND? In general: What should compiler/library vendors see when they define BOOST_STRICT_CONFIG? Just errors in the boost headers or errors in the test files too? -- Genny.

2 1

intrusive_ptr: proposal for common base class
by Stefan Slapeta 26 Jun '04

26 Jun '04

Hi all, Sorry if this has been discussed yet, but I think there is an obvious pattern in the usage of intrusive_ptr which should be exposed as common functionality in boost. In most of the cases you just want to handle a simple reference count and delete the object which is held by the intrusive_ptr when the reference count is decreased to zero. It's very annoying that you currently have to write external add_ref/release functions for every class you want to use with this smart pointer. Additionaly, it makes the code unreadable. That's why I would like to suggest having a base class which provides the simplest functionality a user could expect from intrusive_ptr: handling the reference count and deleting the object. A class which should be maintained by intrusive_ptr can derive from it and would not have to provide any further interfaces. I'm not glad about the class name 'intrusive_ptr_base' but I don't have any good ideas at the moment :( Awaiting you comments! (code: see below) Stefan namespace boost { class intrusive_ptr_base; void intrusive_ptr_add_ref(intrusive_ptr_base*); void intrusive_ptr_release(intrusive_ptr_base*); class intrusive_ptr_base { friend void intrusive_ptr_add_ref(intrusive_ptr_base*); friend void intrusive_ptr_release(intrusive_ptr_base*); int ref_count__; protected: intrusive_ptr_base() : ref_count__(0) {} virtual ~intrusive_ptr_base() {} }; inline void intrusive_ptr_add_ref(intrusive_ptr_base* o) { ++o->ref_count__; } inline void intrusive_ptr_release(intrusive_ptr_base* o) { if (--o->ref_count__ == 0) { delete o; } } } // namespace

2 2

Hmmm.. how do I add a new test to the regressions?
by Fernando Cacciola 26 Jun '04

26 Jun '04

I forgot it.... I need to add the Numeric Conversions Library so I can start hunting compiler problems. Fernando Cacciola SciSoft

2 1

RE: Boost.Threads proposed change: lock constructors
by Batov, Vladimir 25 Jun '04

25 Jun '04

Mike, With all due respect I am not sure that the additional complexity you are proposing is justified. It appears that the differences in lock and try_lock default constructors' behavior are consistent with other libraries and actually feel intuitive and natural to me. After all, it is reflected in what I do -- with lock I try until I succeed (that is [Batov, Vladimir] the lock blocks until succeeds), with try_lock I try once and may fail (that is it unconditionally falls through for me to check the result). Best, V. Date: Thu, 24 Jun 2004 14:14:02 -0400 From: Michael Glassford <glassfordm(a)hotmail.com> Subject: [boost] Boost.Threads proposed change: lock constructors To: boost(a)lists.boost.org Message-ID: <cbf5as$hvv$1(a)sea.gmane.org> Content-Type: text/plain; charset=us-ascii; format=flowed Below I detail proposed changes to the Boost.Threads lock class constructors. Comments? Questions? Mike ----------------------------------------------------------------- The Boost.Threads lock concept constructors are currently defined as follows: Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (type bool, true=locked, false=unlocked) Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s) //Blocking lock if s L l(m) //Non-blocking lock TimedLock Concept ----------------- L l(m,s) //Blocking lock if s L l(m,t) //Blocking lock, failing if not obtained by time t These definitions have the following drawbacks: 1) That one of the TryLock constructors blocks while the other doesn't is neither obvious nor very consistent. 2) That the single-parameter constructor of Lock blocks while the single-parameter constructor of TryLock doesn't is neither obvious nor very consistent. 3) Part of the reason for the above inconsistencies is that it's not clear whether the constructors of TryLock should block or not. 4) The TimedLock constructors have no way to request a non-blocking lock. To address these problems, I would like to redefine the lock concept constructors as follows (changes indicated with "^"): Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,b) //Lock; blocking if b ^ ^^^^^^^^^^^^^ TimedLock Concept ----------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,t) //Blocking lock, failing if not obtained by time t Note: s and b are defined as enums rather than bools to prevent existing code from breaking silently: e.g., if s and b were bools, "TryLock l(m, false)", which currently means "construct a lock object but don't obtain a lock", would change with the new definitions to mean "construct a lock and make a non-blocking attempt to obtain a lock". Also, enums are more explicit than bools. Note: these changes will cause some existing code to break by producing compile errors; the compile errors can be fixed by appropriately adding or changing parameters being passed to the changed TryLock and TimedLock constructors. Mike

2 1

Regression logs oddity
by Gennaro Prota 25 Jun '04

25 Jun '04

Hi everybody, does anyone have hints as to why the Linux regression logs include the first 3 dynamic_bitset test files twice, in two different versions? Example: gcc-3.4.0- linux 3.4.0 ------------------------------------------------------------------- dyn_bitset_unit_tests1 Fail dyn_bitset_unit_tests1 Pass dyn_bitset_unit_tests2 Fail dyn_bitset_unit_tests2 Pass dyn_bitset_unit_tests3 Fail dyn_bitset_unit_tests3 Pass dyn_bitset_unit_tests4 Pass -- Genny.

2 1

dynamic_any campaign?
by fehrin＠t-online.de 25 Jun '04

25 Jun '04

On http://www.cuj.com/boost/ (Boost Corner) the first article is I/O System: dynamic_any campaign by Alexander Nasonov. Is dynamic_any really scheduled for inclusion in boost (1.32 say)? Greetings Franz

3 2

Re:[boost] 1.32 release preparation
by Robert Ramey 25 Jun '04

25 Jun '04

I would very much like to see the serialization library in the 1.32 Release. However, I'm not sure it will be possible to make the posted schedule. I have made all changes to address issues raised in the review. On my personal machine I have passed tests for the compilers VC 7.1 VC 6, gcc 3.3. Borland compiles (almost everything but requires some debug - it will pass most tests) Comeau- compiles everthing - accept for a show stopping problem I've been unable to resolve. My intention has been: a) post version compatible with 1.31 next week. b) build and test against the CVS tree on my computer c) check in In order to do this I need: a) authority to check in b) information on how to mark tests/compilers known to fail. c) I have a couple of questions that I need an expert opinion on. i) the first one is that in order to work, versions for vc 6.0 and borland need to be compiled with spirit 1.61. So the a special environmental variable indicating the directory path where this version of spirit is located on the testing machine. SPIRIT_ROOT. This variable has to be set when serialization libraries are built for these compilers. I should say I'm more than a little bit concerned about changes to mpl and iterators. I'm very much aware of the delays and difficulties associated with the 1.31 release - and it didn't even include this package. So I would like to continue on the path I've established above and we'll see where things stand July 16 when/if you are ready to branch for release. Good Luck ! Robert Ramey

4 4

Random number library
by Oliver Kullmann 25 Jun '04

25 Jun '04

Hi, one of my students tried some time in vain to use the random number generator from the boost library, but he couldn't understand the documentation. I must say, the documentation is not exactly "user-friendly". Here's the problem: Given integers min and max, we want to have a pseudo-random-number generator for random numbers from min, min + 1, ..., max (uniform distribution). The generator should take a seed, and then producing a sequence of pseudo-random numbers (and we should be able to find out about the period of the generator). I couldn't think of anything more basic for a library on random numbers, and so I would expect an example of how to get such a thing in the documentation. (I mean, a real example, complete with code, explanations, and how to use it.) But there's no such a thing, which I find rather strange. We have the concept of a "Uniform Random Number Generator", which looks exactly what we want, but, alas, it seems to be more of a fictitious concept, since no models seem to be provided?!?! So well, let's have a look at "Random Distribution". Only that it needs as input a "Uniform Random Number Generator", and the library does not seem to provide these things?!?! (We have the "Random Number Library Generators", but this library seems to provide only models for the most general concept, the concept of a "Number Generator", but not of a "Uniform Random Number Generator".) Let's ignore this for a moment, and continue our investigations into "Random Distribution". Here are actually some models, most useful for our purpose seems to be "Class template uniform_smallint" and "Class template uniform_int". Now, even if we would know where to get the argument urng from, still we wouldn't know which to choose: The documentation on these class templates is rather cryptic, and additionally asks us to be "wise". Shouldn't this be the job of the library?! Final rescue: "random_demo.cpp". The macros don't enhance readability. But there is an example "Define a uniform random number distribution of integer values between // 1 and 6 inclusive." where I find the text misleading (since we don't define a distribution, which is an assignment of probabilities to certain events, but we define a generator), but looking at the output of the program experiment: roll a die 10 times: 3 3 2 6 6 5 5 6 6 3 it seems to be what we want. So I could copy and past the relevant parts of the program (which is not completely trivial), and I would get close to my goals. If only I would understood the meaning of what I'm doing! Unfortunately, variate_generator.hpp seems to be of some importance, but is not documented. Sigh. --------------------------- My student didn't get to this point, although he is rather good. But there are too many unknowns in the "equation" to solve (starting with the concept of a concept, ...), so the job becomes overwhelming. Now it doesn't look too complicated for me to write a nice explanation for the above problem in a tutorial style, explaining on the way all the concepts and concepts of concepts in the library, and that's what I wanted to kindly request with my e-mail. (And also the rest of the documentation could need a sentence here and there, as mentioned in the above case study.) And, of course, for any example of the best way how to solve the above problem with the library, and explanations how it works, I would be glad! Oliver

4 9

boost::any debug assertion failed in destructor
by Olivier Tristan 25 Jun '04

25 Jun '04

Hi guys, I'm currently trying got use boost::any to create some container with different type and I'm having some trouble with a small exemple. I try this on VC2003, VC2002 and gcc 3.3 Here is my class class A { public: A(unsigned long size) : mSize(size), mBuffer(new boost::any[size]) {} ~A() { delete mBuffer; } private: unsigned long mSize; boost::any *mBuffer; }; int main(void) { A(256); return 0; } and I got an assertion in the destructor of A; Can someone tell me if I did something wrong or if there is some problem is boost::any Thanks, -- Olivier Tristan Ultimate Sound Bank

2 2